Allocating partial payment of a transaction amount using an allocation rule

ABSTRACT

A financial account issuer facilitating transactions between accounts is disclosed. The invention provides sellers with an irrevocable method of receiving funds from a purchaser and for improving purchaser willingness to transact with an unknown party. The invention also enables the allocation of a portion or all of a charge or loyalty points to different transaction accounts issued by different issuers, or to sub-accounts.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation in part, and claims priority to, U.S.patent application Ser. No. 11/695,152, filed on Apr. 2, 2007. The '152application claims priority to U.S. Pat. No. 7,426,492, issued on Sep.16, 2008. The '492 patent claims benefit from provisional applicationSer. No. 60/163,824, filed Nov. 5, 1999, and provisional applicationSer. No. 60/164,075, filed Nov. 5, 1999. All of the foregoing are herebyincorporated by reference.

FIELD OF THE INVENTION

The present invention generally relates to financial transactions and,more particularly, to the facilitation of transactions between twoaccounts.

BACKGROUND OF THE INVENTION

The advent of the Internet has rendered electronic commerce (e-commerce)one of the fastest growing segments of the global economy. The growth ofe-commerce is due, in part, to the ever-expanding array of goods andservices available to online users and the ease with which Internetaccess can be obtained. Each year, as general use of, and familiaritywith, the Internet becomes more pervasive, the number of commercialtransactions facilitated by the Internet is expected to escalatedramatically. The Internet is easily accessible, and the products andservices available to users of the network are virtually limitless. Inaddition to allowing large merchants to sell products and services, theInternet offers a platform through which geographically remote smallmerchants and individuals can easily conduct a variety of transactionswith each other. Thus, the Internet represents an opportunity for theexercise of unparalleled consumer purchasing power.

However, a number of hurdles impedes the typical Internet user fromengaging in a variety of online transactions and, therefore, fromeffectively leveraging this purchasing power. As the number and scope oftransactional opportunities available to Internet users expand,individual users seeking to exploit these opportunities are squarelyconfronted with the significant challenge of transferring and receivingmonetary value online, regardless of whether the transfer and/or receiptof monetary value culminates in an online sales transaction or whetherit effects a simple funds transfer between individual users. While theInternet has become an extraordinarily efficient mechanism for thedissemination of information, the development of effective, secure meansfor engaging in online transactions for value has proved problematic andhas been a significant factor in slowing the acceptance and growth ofe-commerce.

Generally, methods of transferring and receiving funds for onlinetransactions can be separated into two broad categories: online andoff-line. Online methods of transferring funds typically includetransactions involving either the transmission of credit cardinformation or the use of some form of digital cash. However, manyindividual Internet users are acutely aware that the transmission ofcredit card numbers over the Internet carries the risk of theft fromunscrupulous computer hackers and thieves who have the ability to tapinto servers connected to the Internet. Since credit card numberstypically comprise sixteen-digit numbers having a publicly knownpattern, once a computer hacker has accessed an appropriate server, thehacker can simply search the server for messages containing numbershaving a recognized pattern and enjoy a fair degree of confidence thatthe results of such a search will yield messages that likely correspondto valid credit cards. Off-line methods are usually safer in thisregard, as they may require that a check or some other cash equivalent,such as a money order, be sent through the mail. Nevertheless, thislatter approach is generally cumbersome, time consuming, and commonlyperceived as troublesome to the average Internet user. Moreover, none ofthese methods, either online or off-line, sufficiently addresses thelogistics involved in satisfactorily coordinating both the transfer ofmonetary value from a first user to a second user and the transfer ofgoods, services, or other value from the second user to the first user.

Another hurdle that often impedes widespread acceptance of commercialtransactions between individual Internet users is that, since theInternet facilitates remote person-to-person communication, most onlinetransactions suffer from a tenuous connection between the parties to thetransaction. For example, unlike the experience provided by conventional‘brick and mortar’ stores, in the case of a typical online transactioninvolving the purchase of goods, online purchasers generally do notinteract personally with sellers and often do not receive the same levelof customer service due to the nature of the seller involved in thetransaction, as well as the character of Internet communications.Although purchasers and sellers occasionally can communicate effectivelyeither online or by telephone, purchasers often cannot examine thequality of the goods that they are interested in purchasing. Frequently,an individual purchaser's inability to inspect the goods prior toremitting payment and/or the purchaser's lack of knowledge of theseller's integrity, in conjunction with other factors, createssufficient apprehension in a purchaser's mind to derail an intendedonline purchase. Moreover, even if an individual purchaser overcomes aninitial hesitancy and decides to engage in a online transaction with anindividual seller, the nature of the transaction is such that thepurchaser generally has little recourse in the event that the sellerfails to deliver the goods or services as promised or that the goods orservices are damaged or otherwise misrepresented. Conversely, the selleralso has little recourse should the purchaser ultimately decide toabandon the transaction.

In the context of commercial transactions conducted between individualInternet users, an additional shortcoming of conventional paymentschemes is that there are few ways for an individual purchaser totransfer monetary value to an individual seller, with the exception ofcash, such that the seller may use the value transferred without firstprocessing the transfer instrument by, for example, depositing theinstrument with a bank or converting it into cash. In other words, therecipient of a check or other negotiable instrument must use a financialinstitution to mediate the conversion of the transferred value intovalue that the recipient can use in its own behalf. Furthermore, usingconventional means for transferring currency between individuals, aseller may not receive financial tender until two to four weeks afterperformance of a service or shipment of the goods to the individualpurchaser. Moreover, since a seller frequently has inventory costsassociated with the particular goods offered for sale, this can resultin the loss of valuable interest, pending the arrival of a paymentthrough the mail and/or sufficient time for a bank deposit of thatpayment to clear the seller's bank account.

Furthermore, in the case of an online seller who is not a large merchantand who generally is not capable of accepting credit card payments, theability to engage in a particular transaction with another Internet usermay necessitate that the seller enter into an agreement with a creditcard issuer to enable the seller to receive monetary value from theother Internet user. Not only are such agreements time consuming andcostly, but conducting a financial transaction in accordance with suchan agreement often requires the seller to communicate confidentialinformation, such as credit card numbers, to third parties, such ascredit card issuers, thereby risking the security of the confidentialinformation. Although alternative payment schemes, such as digital moneysystems (e.g., DigiCash, e-Cash, etc.) are readily envisioned, most arestill in the early stages of development and no standards regardingtheir use have been established as of yet.

Significantly, the foregoing factors frequently adversely impact anindividual user's willingness to engage in online commercialtransactions at all. Thus, the volume of conventional online andoff-line transactions for exchanging monetary value is reduced. Theselosses may be due either to the individual seller's inability to processcredit card transactions or to the individual purchaser's apprehensionregarding acceptance of the risks associated with remitting onlinepayments. Consequently, there is a need for systems and methods whichenable remote individuals, such as Internet users, to transfer monetaryvalue in exchange for goods, services, or other value in a securemanner. There is also a need for systems and methods which enable remoteindividuals to receive monetary value from each other and to utilize thevalue represented by the funds transfer immediately. There is also aneed for systems and methods which enable individuals who do nottypically process credit card transactions to receive monetary valuefrom other individuals without being required to communicateconfidential information to a third party and possibly risking a breachin the security of such information. There is an additional need forsystems and methods which permit an individual seller to receivepre-authentication or pre-authorization of an individual purchaser'sability to transfer sufficient funds to complete a commercialtransaction. There is also a need for systems and methods which reducethe risks associated with commercial transactions between remoteindividuals. Finally, there is also a need for systems and methods whichprovide dispute resolution mechanisms to remote individuals engaging incommercial or financial transactions conducted, for example, over adistributed computer network.

SUMMARY OF THE INVENTION

The present invention facilitates commercial transactions involving theexchange of monetary value for goods, services, or other value betweenremote individuals, such as users of a distributed computer network orInternet users. The present invention provides remote sellers with anirrevocable means of receiving funds from a remote purchaser; means forimproving purchaser willingness to transact with an unknown party;transaction tracking; and rapid funds availability. The presentinvention also provides remote purchasers with means for making asecure, confidential transfer of funds; means for immediate initiationof shipment by a seller; means for releasing funds to a seller onlyafter approval of the goods, services, or other value received from theseller; means for demonstrating proof of payment; and means for havingsome level of recourse against a remote seller.

The transfers discussed herein may be related to a purchase transaction,an exchange of an item (e.g., good, service, information, experience,access, entertainment, etc), no item exchange, a loan to another account(e.g., debiting a loan amount from a first account and charging a loanamount to a second account), transferring credit to another account,cost splitting, budgeting, spend compartmentalization, gifting, currencyexchanges, currency exchange rates, loyalty points, monetaryequivalents, non-monetary items and/or the like.

More particularly, the system and method enables a financial accountissuer to facilitate a transaction by: receiving, at the financialaccount issuer, a request to debit a first amount from a first financialaccount having a first identifier associated with the first financialaccount, wherein the financial account issuer issued the first financialaccount, and wherein the financial account issuer comprises a server;receiving, at the financial account issuer, a request to credit at leasta portion of the first amount to a second financial account having asecond identifier associated with the second financial account;determining, by the financial account issuer, if at least one of therequest to debit the first financial account or the request to creditthe second financial account is fraudulent; facilitating debiting, bythe financial account issuer, the first amount from the first financialaccount, if the request to debit the first financial account is notfraudulent; and, facilitating crediting, by the financial accountissuer, at least a portion of the first amount to the second financialaccount, if the request to credit the second financial account is notfraudulent.

Registration of either a first party or a second party may includeproviding the transaction mechanism with a suitable financial accountidentifier, such as a card number, demand deposit account (DDA) number,or any suitable part of the number, to identify the financial account ofeither the first party or the second party. Moreover, transactioninformation received from at least one of the first party and the secondparty can include a financial account identifier associated with thefinancial account of the first party. Furthermore, a request for avalue-added service can be received from the first party and/or thesecond party, and receiving the request for a value-added service canfurther include receiving a request for a value-added service such asinsurance, dispute resolution, postal tracking, and/or the like.Additionally, determining whether the transaction is acceptable canfurther include a credit risk analysis and/or a fraud detectionanalysis.

BRIEF DESCRIPTION OF THE DRAWINGS

Additional aspects of the present invention will become evident uponreviewing the non-limiting embodiments described in the specificationand the claims taken in conjunction with the accompanying figures,wherein like numerals designate like elements, and:

FIG. 1 is an exemplary schematic diagram of a prior art system forconducting a commercial transaction between parties who are remotelylocated from one another;

FIGS. 2-4 are schematic block diagrams illustrating exemplarytransaction systems in accordance with various aspects of the presentinvention;

FIG. 5 is a schematic block diagram of an exemplary transactionmechanism in accordance with the present invention;

FIG. 6 is a flowchart representing an exemplary commercial transactionin accordance with the present invention;

FIG. 7 is a flowchart of an exemplary transactional mechanism inaccordance with the present invention;

FIG. 8 is a schematic block diagram of the process flow for an exemplarytransaction system in accordance with the present invention;

FIG. 9 is a schematic relational diagram associating exemplary actorsand exemplary transaction processes in accordance with the presentinvention;

FIG. 10 is an exemplary interface for facilitating user registrationwith the transaction mechanism;

FIG. 11 is an exemplary interface for facilitating user login with thetransaction mechanism;

FIG. 12 is an exemplary interface for facilitating transactioninitiation;

FIG. 13 is a flowchart representing an exemplary seller-initiatedtransaction;

FIG. 14 is an exemplary interface for facilitating the entry oftransaction information by a user;

FIG. 15 is an exemplary interface depicting an exemplary transactioninvoice;

FIG. 16 is an exemplary interface for informing a user of thecancellation of a transaction;

FIG. 17 is a flowchart representing an exemplary purchaser transactionconfirmation;

FIG. 18 is an exemplary interface for facilitating the entry oftransaction information by a user;

FIGS. 19A and 19B represent an exemplary interface depicting anexemplary transaction invoice;

FIG. 20 is an exemplary interface for informing a user of thenon-acceptance of a transaction;

FIG. 21 illustrates an exemplary transaction mechanism in accordancewith various aspects of the present invention; and

FIG. 22 represents an exemplary system for processing the submission offinancial transactions.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

The present invention may be described herein in terms of functionalblock components, screen shots, optional selections, and variousprocessing steps. It should be appreciated that such functional blocksmay be realized by any number of hardware and/or software componentsconfigured to perform the specified functions. For example, the presentinvention may employ various integrated circuit components, e.g., memoryelements, processing elements, logic elements, look-up tables, and thelike, which may carry out a variety of functions under the control ofone or more microprocessors or other control devices. Similarly, thesoftware elements of the present invention may be implemented with anyprogramming or scripting language such as C, C++, Java, COBOL,assembler, PERL, or the like, with the various algorithms beingimplemented with any combination of data structures, objects, processes,routines or other programming elements. Further, it should be noted thatthe present invention may employ any number of conventional techniquesfor data transmission, signaling, data processing, network control, andthe like. For a basic introduction to cryptography, please review a textwritten by Bruce Schneider which is entitled “Applied Cryptography:Protocols, Algorithms, And Source Code In C,” published by John Wiley &Sons (second edition, 1996), which is hereby incorporated by reference.

It should be appreciated that the particular implementations shown anddescribed herein are illustrative of the invention and its best mode andare not intended to otherwise limit the scope of the present inventionin any way. Indeed, for the sake of brevity, conventional datanetworking, application development, and other functional aspects of thesystems (and components of the individual operating components of thesystems) may not be described in detail herein. Furthermore, theconnecting lines shown in the various figures contained herein areintended to represent exemplary functional relationships and/or physicalcouplings between the various elements. It should be noted that manyalternative or additional functional relationships or physicalconnections may be present in a practical electronic transaction system.

It will be appreciated that many applications of the present inventioncould be formulated. One skilled in the art will appreciate that thenetwork may include any system for exchanging data or transactingbusiness, such as the Internet, an intranet, an extranet, WAN, LAN,satellite communications, and/or the like. The users may interact withthe system via any input device such as a keyboard, mouse, kiosk,personal digital assistant, handheld computer (e.g., Palm Pilot®),cellular phone, and/or the like. Similarly, the invention could be usedin conjunction with any type of personal computer, network computer,workstation, minicomputer, mainframe, or the like running any operatingsystem such as any version of Windows, Windows NT, Windows 2000, Windows98, Windows 95, MacOS, OS/2, BeOS, Linux, UNIX, or the like. Moreover,although the invention is frequently described herein as beingimplemented with TCP/IP communications protocols, it will be readilyunderstood that the invention could also be implemented using IPX,Appletalk, IP-6, NetBIOS, OSI, or any number of existing or futureprotocols. Moreover, the system contemplates the use, sale, ordistribution of any goods, services, or information over any networkhaving similar functionality described herein.

The customer and merchant may represent individual people, entities, orbusinesses. Although labeled as a “bank,” the bank may represent othertypes of card issuing institutions, such as credit card companies, cardsponsoring companies, or third party issuers under contract withfinancial institutions. It is further noted that other participants maybe involved in some phases of the transaction, such as an intermediarysettlement institution, but these participants are not shown.

Each participant is equipped with a computing system to facilitateonline commerce transactions. The customer has a computing unit in theform of a personal computer, although other types of computing units maybe used, including laptops, notebooks, hand held computers, set-topboxes, and the like. The merchant has a computing unit implemented inthe form of a computer-server, although other implementations arepossible. The bank has a computing center shown as a main framecomputer. However, the bank computing center may be implemented in otherforms, such as a mini-computer, a PC server, a network set of computers,and/or the like.

The computing units are connected with each other via a datacommunication network. The network is a public network and assumed to beinsecure and open to eavesdroppers. In the illustrated implementation,the network is embodied as the internet. In this context, the computersmay or may not be connected to the Internet at all times. For instance,the customer computer may employ a modem to occasionally connect to theInternet, whereas the bank computing center might maintain a permanentconnection to the Internet. It is noted that the network may beimplemented as other types of networks, such as an interactivetelevision (ITV) network.

The merchant computer and the bank computer are interconnected via asecond network, referred to as a payment network. The payment networkrepresents existing proprietary networks that presently accommodatetransactions for credit cards, debit cards, and other types offinancial/banking cards. The payment network is a closed network that isassumed to be secure from eavesdroppers. Examples of the payment networkinclude the American Express®, VisaNet®, and the Veriphone® networks.

The electronic commerce system is implemented at the customer andissuing bank. In an exemplary implementation, the electronic commercesystem is implemented as computer software modules loaded onto thecustomer computer and the banking computing center. The merchantcomputer does not necessarily require any additional software toparticipate in the online commerce transactions supported by the onlinecommerce system.

As will be appreciated by one of ordinary skill in the art, the presentinvention may be embodied as a method, a data processing system, adevice for data processing, and/or a computer program product.Accordingly, the present invention may take the form of an entirelysoftware embodiment, an entirely hardware embodiment, or an embodimentcombining aspects of both software and hardware. Furthermore, thepresent invention may take the form of a computer program product on acomputer-readable storage medium having computer-readable program codemeans embodied in the storage medium. Any suitable computer-readablestorage medium may be utilized, including hard disks, CD-ROM, opticalstorage devices, magnetic storage devices, and/or the like.

The present invention is described below with reference to blockdiagrams and flowchart illustrations of methods, apparatus (e.g.,systems), and computer program products according to various aspects ofthe invention. It will be understood that each functional block of theblock diagrams and the flowchart illustrations, and combinations offunctional blocks in the block diagrams and flowchart illustrations,respectively, can be implemented by computer program instructions. Thesecomputer program instructions may be loaded onto a general purposecomputer, special purpose computer, or other programmable dataprocessing apparatus to produce a machine, such that the instructionswhich execute on the computer or other programmable data processingapparatus create means for implementing the functions specified in theflowchart block or blocks.

These computer program instructions may also be stored in acomputer-readable memory that can direct a computer or otherprogrammable data processing apparatus to function in a particularmanner, such that the instructions stored in the computer-readablememory produce an article of manufacture including instruction meanswhich implement the function specified in the flowchart block or blocks.The computer program instructions may also be loaded onto a computer orother programmable data processing apparatus to cause a series ofoperational steps to be performed on the computer or other programmableapparatus to produce a computer-implemented process such that theinstructions which execute on the computer or other programmableapparatus provide steps for implementing the functions specified in theflowchart block or blocks.

Accordingly, functional blocks of the block diagrams and flowchartillustrations support combinations of means for performing the specifiedfunctions, combinations of steps for performing the specified functions,and program instruction means for performing the specified functions. Itwill also be understood that each functional block of the block diagramsand flowchart illustrations, and combinations of functional blocks inthe block diagrams and flowchart illustrations, can be implemented byeither special purpose hardware-based computer systems which perform thespecified functions or steps, or suitable combinations of specialpurpose hardware and computer instructions.

As background, FIG. 1 illustrates an exemplary prior art method forconducting an online commercial transaction between individual users ofa distributed computer network, such as the Internet. Initially,individual users contact each other over the network and agree to theterms of a transaction (step 1). If the particular transaction is asales transaction involving goods, for example, the purchaser mails acheck, money order, or other suitable negotiable instrument to theseller (step 2). Once the seller receives the negotiable instrument, theseller deposits it with an appropriate financial institution, such as abank (step 3). When the bank clears the check through the seller'saccount, the seller is given access to the funds (step 4). The sellerthen ships the goods to the purchaser (step 5), and the purchaserreceives the goods (step 6). Generally, this process involves an elapsedtime of approximately two to three weeks before the seller receives“good funds” for the transaction, and three to four weeks until thepurchaser receives the goods. Moreover, this process may include thepurchaser disclosing his/her name and address to the seller to effectthe transaction, and the purchaser has little or no recourse if eitherthe seller fails to deliver the goods as promised or the goods aredamaged or otherwise misrepresented.

The present invention comprises systems, methods, and computer programproducts for facilitating commercial transactions between remoteindividuals, wherein the transactions often include person-to-persontransfers of funds. In a preferred aspect, the present inventionfacilitates commercial transactions comprising sales transactionsconducted between remote individuals, such as transactions between usersof a distributed computer network. One skilled in the art willappreciate that the phrase “person-to-person transfers of funds”, asused herein, includes, for example, transfers from a financial accountof a first party, which may be an individual or an entity, to thefinancial account of a second party, which may be an individual or anentity. One skilled in the art further will appreciate that a “financialaccount” or “account” can include a card account, a demand depositaccount, a credit line, a money market account, a digital cash account,and/or any other financial account. Thus, a person-to-person transfer offunds can include card to card transfers of monetary value, card todemand deposit account (DDA) funds transfers, DDA to card transfers,card to credit line transfers, credit line to card transfers, and/or thelike. Moreover, funds transfers in accordance with the present inventioncan be between financial accounts held with either the same financialinstitution or different financial institutions. A “financialinstitution”, as will be appreciated by one of ordinary skill in theart, can include any suitable third party, such as a bank, a cardissuer, a lender, a credit union, and/or the like.

Further, as one skilled in the art will appreciate, a “transaction card”or “card”, as used herein, includes any device, code, or suitablefinancial instrument representing an account with a financialinstitution, such as a bank, a card issuer, and/or the like, wherein thedevice, code, or other suitable financial instrument has a credit lineor balance associated with it, and wherein the credit line or balance isin a form of a financial tender having discrete units, such as currency.Moreover, a “transaction card” or “card”, as used herein, includes anydevice, code, or financial instrument suitably configured to allow thecardholder to interact or communicate with the system, such as, forexample, a charge card, credit card, debit card, prepaid card, telephonecard, smart card, magnetic stripe card, bar code card,authorization/access code, personal identification number (PIN),Internet code, other identification code, and/or the like. Additionally,a “cardholder” or “cardmember” includes any person or entity which usesa transaction card and participates in the present system and mayinclude a person who is simply in possession of a financial accountidentifier, such as an authorization or account code. Similarly, a“demand deposit account” may include any suitable financial account,such as a bank account (e.g., checking, savings, money market, creditline, etc.) or other financial account maintained by a third party (suchas a suitably insured financial institution), such account preferablyhaving a balance of substantially the same financial tender as the card.

Communication between the parties to the transaction and the system ofthe present invention is accomplished through any suitable communicationmeans, such as, for example, a telephone network, Intranet, Internet,point of interaction device (point of sale device, personal digitalassistant, cellular phone, kiosk, etc.), online communications, off-linecommunications, wireless communications, and/or the like. One skilled inthe art will also appreciate that, for security reasons, any databases,systems, or components of the present invention may consist of anycombination of databases or components at a single location or atmultiple locations, wherein each database or system includes any ofvarious suitable security features, such as firewalls, access codes,encryption, de-encryption, compression, decompression, and/or the like.

While a person-to-person transfer may generically be described as atransfer from the financial account of a first party to a financialaccount of a second party, for convenience and purposes of brevity andconsistency, the present disclosure generally refers to the first partyas the purchaser and the second party as the seller. However, it will berecognized by those of ordinary skill in the art that the seller neednot provide goods or services to the purchaser in exchange for thetransfer of funds. While this often may be the case, the presentdisclosure is not so limited and includes transactions which may begratuitous in nature, whereby the purchaser transfers funds from theirfinancial account to the financial account of the seller without theseller providing any goods, services, or other value in exchange.

In accordance with an aspect of the present invention, aperson-to-person funds transfer may be facilitated by any suitablefinancial institution, such as a card issuer like American Express®Company for example, which suitably provides credit risk analysis andfraud risk analysis in essentially real-time, unlike other card-basedfund transfer schemes which rely on third parties to facilitate suchservices. Utilization of third-party credit risk and fraud riskanalyses, such as used in conventional funds transfer schemes, not onlymay increase the amount of time to process the funds transfer, but alsomay jeopardize the security of confidential information associated withthe transaction due to the typical need for multiple transmissions ofthe relevant information. Furthermore, by reducing the participants inthe transaction and by enabling the card issuer to facilitate the fundstransfer, certain transaction fees and/or costs may be reduced oravoided entirely because the card issuer is positioned to profit fromthe increased card use, rather than simply profiting from the feesassociated with the manner in which the card is used by individualpurchasers.

In accordance with an aspect of the present invention, FIG. 2 is adiagram illustrating an exemplary transaction system 200. Thetransaction system 200 comprises a transaction mechanism or server 202which facilitates and controls commercial transactions between apurchaser 204 and a seller 206. In order to complete the funds transferfrom the financial account of the purchaser 204 to the financial accountof the seller 206, the transaction mechanism 202 communicates with atleast one of a seller's financial institution 208, which comprises asuitable financial account associated with the seller 206, and apurchaser's financial institution 210, which comprises a suitablefinancial account associated with the purchaser 204. In the case wherethe seller's financial account comprises a demand deposit account, forexample, the seller's account can include, for example, a bank account,such as a savings, checking, or money market account associated with theseller 206. In an exemplary embodiment, the communication link betweenthe transaction mechanism 202 and the seller's financial institution 208can comprise a suitable connection to an automated clearinghouse (ACH)for facilitating bank checking account transfers, as is well-known tothose in the industry.

In an exemplary embodiment, the purchaser's financial institution 210may comprise the transaction mechanism 202. In another exemplaryembodiment, transaction mechanism 202 is maintained by an independentthird party, such as an intermediary 314, as described more fully belowwith reference to FIG. 3. The communication links between and among thetransaction mechanism 202, purchaser 204, seller 206, seller's financialinstitution 208, and purchaser's financial institution 210 can beimplemented through one or more communications networks, such as aprivate extranet, a public Internet, and/or a third party extranet,though it will be recognized by those skilled in the art that othernetworks such as a public switch telephone network (PSTN) likewise maybe utilized. Moreover, although the present invention may be suitablyimplemented with TCP/IP protocols, it will be readily appreciated thatthe invention also can be implemented using IPX, Appletalk, IP-6,NetBIOS, OSI, or any number of other protocols either currently known orhereafter devised. Further, in another exemplary embodiment, purchaser204 and seller 206 are implemented by any suitable type of personalcomputer, point of interaction device, network computer, workstation,minicomputer, mainframe, and/or the like, which implementationpreferably includes a suitable browser application, such as a World WideWeb (Web) browser, preferably having suitable encryption capability.

In accordance with the present invention, it is preferred that eitherone or both of the purchaser 204 and seller 206 pre-register with thetransaction mechanism 202. However, as those skilled in the art willappreciate, a specific registration of the purchaser 204 and/or theseller 206 is not required and registration may take place at anysuitable time, including at the time of the transaction. Duringpurchaser registration, the purchaser 204 preferably provides suitablefinancial account information, such as card information for example, andsuitable purchaser identification information. In an exemplaryembodiment, the purchaser identification and/or account informationincludes any suitable information related to the purchaser and/or theaccount, such as any one or more of the following: name, address,demographic information, social security number, telephone number,account number, account expiration date, personal identification numberassociated with the account, date of birth, mother's maiden name,spending habit information, billing history information, credit historyinformation, and/or any additional information which might identify thepurchaser and the purchaser's financial account. The purchaseridentification information can be used for subsequent purchaserauthentication. During seller registration, the seller 206 preferablyprovides suitable financial account information and suitableidentification information relating to an account, such as anappropriate card or demand deposit account for example, at the seller'sfinancial institution 18. The seller's identification information can beused for subsequent authentication. In an exemplary embodiment, one orboth of the purchaser 204 and seller 206 are cardmembers or cardholdersof the card issuer which is providing the transaction mechanism 202,thereby expediting and streamlining the registration process and, inanother exemplary embodiment, subsequent authentication and credit/fraudanalysis processes performed by the transaction mechanism 202.

As illustrated in FIG. 2, a transaction 212 may be initiated by one ofeither the purchaser 204 or the seller 206. The transaction 212, whichis illustrated in phantom lines in order to represent that it isoptional, may comprise the exchange of goods, services, or other valuefrom the seller 206 to the purchaser 204 in exchange for a transfer offunds from the purchaser's financial account at the purchaser'sfinancial institution 210 to the seller's financial account at seller'sfinancial institution 208. However, it should be appreciated thattransaction 212 need not comprise an exchange of goods and/or services,but rather, may comprise a gratuitous transfer of funds from a purchaser204 to a seller 206. By way of example, the purchaser 204 may bepurchasing goods from the seller 206 which goods were identified througha classified ad, an Internet posting, an Internet auction, and/or thelike, or, alternatively, the purchaser 204 may be transferring funds tothe seller 206 for philanthropic, charitable, or other gift-givingpurposes. Thus, depending upon the nature of the transaction 212, one ofeither the purchaser 204 or the seller 206 will initiate the transfer offunds by suitably providing to the transaction mechanism 202 transactioninformation. The transaction information may include identificationinformation regarding one or both of the purchaser 204 and the seller206 as well as the terms of the transaction, which can include suitableaccount information, the date and time of the transaction, the amount ofthe funds transfer, a description of the goods, services, or othervalue, any escrow terms (such as a suitable escrow release event),and/or the like. In addition, requests for value-added services, such asinsurance, dispute resolution, postal tracking, and/or the like may bemade by one or both of the purchaser 204 and/or the seller 206.

The transaction mechanism 202 then suitably authenticates the seller 206and/or the purchaser 204 to ensure that they are the appropriate ownersof their respective accounts. In an exemplary embodiment, thetransaction mechanism 202 is provided by the purchaser's financialinstitution 210, such as the card issuer of a purchaser's card forexample, which financial institution is able to perform suitable riskmanagement functions, such as suitable credit risk and/or fraud riskanalyses for example. The ability of the transaction mechanism 202,through a suitable financial institution which preferably maintains andoperates the transaction mechanism 202, to perform credit risk and fraudrisk analyses is particularly advantageous, since performance of theseservices by a third party not only delays the transaction process butpresents an additional security risk when transmitting and processingconfidential or transaction-sensitive information to and from the thirdparty. Moreover, when the transaction mechanism 202 is provided by thepurchaser's financial institution 210, such as a card issuer,information such as historical transactional records, account records,and/or the like easily can be reviewed to determine whether a credit orfraud risk exists.

In another exemplary embodiment, the transaction mechanism 202 suitablydetermines whether the purchaser's financial account has a sufficientbalance to enable the funds transfer identified in the transactioninformation. If the purchaser 204 has sufficient funds available in thefinancial account, and suitable risk management and authenticationprocesses do not result in a negative determination, the transaction isdeemed acceptable. The transaction mechanism 202 then executes thetransaction by debiting the purchaser's financial account and creditinga suitable escrow account maintained by the transaction mechanism 202.The funds debited from the purchaser's financial account preferablyremain in the escrow account for some predefined period of time. Thepredefined period of time may be based upon the occurrence of a suitablydefined escrow release event, such as any of the following events:receipt by the purchaser of the goods, services, or other value; thelapse of a predetermined period of time within which the purchaser mayevaluate the goods, services, or other value and either accept or refusedelivery; and/or any other suitable, predefined event. Preferably, thetransaction mechanism 202 withholds the funds from the seller'sfinancial account and suitably maintains the funds in the escrow accountpending the occurrence of the escrow release event. Debiting of theescrow account and crediting of the seller's financial account for theamount of the funds transfer occurs once the escrow release event hastranspired and the purchaser has not rejected the shipment.

In another exemplary embodiment, the transaction mechanism 202 may besuitably configured to include a transaction fee in the amount debitedfrom the purchaser's financial account, and/or the transaction mechanism202 may be suitably configured to subtract a transaction fee from theamount credited to the seller's financial account. In an exemplaryembodiment, the transfer of funds to the seller's financial account fromthe escrow account includes suitable communications with an ACH, as willbe appreciated by one of ordinary skill in the art.

In an exemplary embodiment, the transaction mechanism 202 providesvalue-added services which may be requested by the purchaser 204 and/orthe seller 206 as a part of the transaction between the parties.Preferably, the value-added services may include insurance, disputeresolution, postal tracking, and/or similar services that potentiallyenhance the value of the transaction to the purchaser 204 and/or theseller 206. In the event that value-added services are requested by thepurchaser 204 as a part of the funds transfer, then the cost of suchservices is included in the amount of funds debited or deducted from thepurchaser's financial account. Likewise, the cost of value-addedservices requested by the seller 204 are suitably withheld or deductedfrom the funds credited or added to the seller's financial account.

In accordance with another aspect of the present invention, FIG. 3 is adiagram illustrating an exemplary transaction system 300. Thetransaction system 300 comprises an intermediary 314 which suitablyprovides an interface between the purchaser 304 and the seller 306. Theintermediary 314 can be any suitable third party. In an exemplaryembodiment, intermediary 314 can include an online auction such as eBay®or eWanted®, an online merchant such as Amazon.com®, an onlineclassified ad site, and/or the like. By way of example, if theintermediary 314 is eBay, the seller 306 may list goods for sale throughthe intermediary 314, for which a purchaser 304 may then submit bids.The intermediary 314 then suitably determines whether the purchaser 304submitted the highest bid and, if so, then makes a final saledetermination, which can include sending appropriate notice, such as bye-mail for example, to both the purchaser 304 and the seller 306. Oncenotified, the purchaser 304 is provided with the opportunity to selectmeans for submitting payment to the seller 306, such as through asuitable card or DDA. For example, by selecting the card payment method,transaction information regarding the sale is transferred byintermediary 314 to a suitable transaction mechanism 302 provided by asuitable financial institution, such as a card issuer

As described above with reference to FIG. 2, the seller 306 preferablyis pre-registered with the transaction mechanism 302, and the seller'sfinancial account at the seller's financial institution 308 may suitablyreceive appropriate funds transferred from the purchaser's financialaccount at the purchaser's financial institution 310. If the purchaser304 is not pre-registered, purchaser registration may take place at thetime of the transaction with the seller 306. As discussed above, thetransaction mechanism 302 receives transaction information regarding thesale, authenticates the purchaser 304 and the seller 306, and performssuitable credit and fraud risk management analyses. If the purchaser 304has sufficient funds available in their financial account and the riskmanagement and authentication processes do not result in a negativedetermination, then the transaction mechanism 302 deems the transactionacceptable and debits suitable funds from the purchaser's financialaccount. Preferably, as described above with reference to FIG. 2, asuitable escrow account maintained by the transaction mechanism 302 iscredited with the funds transferred from the purchaser's financialaccount. Upon the occurrence of a suitably predefined or pre-identifiedescrow release event, the escrow account is suitably debited and theseller's financial account is suitably credited with the funds. Again,as described above, any suitable transaction or service fees arepreferably included in the amount of funds debited and transferred fromthe purchaser's financial account and/or deducted from the amount offunds disbursed and credited to the seller's financial account.

As is often the case with an intermediary 314, such as eBay, thetransaction between the seller 306 and the purchaser 304 may involve theshipment of goods from the seller 306 to the purchaser 304.Consequently, as typically determined by the particular business rulesof the intermediary 314, the goods are shipped by a suitable shippingagent 316 from the seller 306 to the purchaser 304. Preferably, as apart of the escrow service performed by the transaction mechanism 302, atracking number will be provided by the shipping agent to thetransaction mechanism 302. Upon confirmation that the purchaser 304 hasreceived the goods, the transaction mechanism suitably transfers theappropriate funds to the seller's financial account. Preferably, theshipping agent 316 confirms that the purchaser 304 has received thegoods. More preferably, the transaction mechanism 302 only releases thefunds to the seller 306 upon the suitable occurrence of any predefinedescrow release event, such as the lapse of a specified period of time inwhich the purchaser 304 may evaluate and either accept or reject thegoods. In the case that the escrow release event is not satisfied orthat the purchaser 304 rejects the goods, the transaction may besuitably reversed or otherwise abandoned. In the event that there is adispute between a purchaser 304 and a seller 306 regarding a particulartransaction, the financial institution that maintains the transactionmechanism 302 may provide the parties with a suitable dispute resolutionmechanism, such as access to any suitable system for providing customerservice for example.

In an exemplary embodiment, anonymity or portions of anonymity betweenthe purchaser 304 and seller 306 is suitably maintained throughout thetransaction between the parties. One skilled in the art will appreciatethat any subset of information may remain anonymous. Preferably, theonly purchaser information that is transmitted and known to the seller306 is the purchaser's user identifier. Likewise, it is preferred thatthe purchaser's knowledge of the seller 306 is limited to the seller'suser identifier. In other words, both the purchaser 304 and the seller306 need not disclose their name, address, financial accountinformation, or any other confidential information to one another inorder to effect the transaction. In this embodiment, the purchaser 304and seller 306 suitably provide their name, address, financial accountinformation, and any other necessary information to the transactionmechanism 302 upon registering with the transaction mechanism 302. Inthis manner, the shipping agent 316 suitably obtains the relevantpurchaser shipping information from the transaction mechanism 302 toobviate any need for a seller 306 to have access to confidentialidentification information of a purchaser 304.

It should be understood that while FIG. 3 illustrates respectivecommunication links between the transaction mechanism 302 and both thepurchaser 304 and the seller 306, the scope of the present inventionextends to the transmission of information, such as registrationinformation, transaction information, and/or the like, from either orboth of the purchaser 304 and/or the seller 306 directly to theintermediary 314 and then from the intermediary 314 to the transactionmechanism 302. In other words, the intermediary 314 may mediate the flowof information from either/both the purchaser 304 and/or the seller 306to the transaction mechanism 302 without any direct communicationbetween the either the purchaser 304 or the seller 306 and thetransaction mechanism 302. Moreover, the intermediary 314 maycommunicate directly with the transaction mechanism 302 through asuitable communications link or, alternatively, the transactionmechanism 302 may be integrated with the intermediary 314, asillustrated in the exemplary transaction system 400 of FIG. 4. Inaccordance with this aspect of the present invention, the transactionmechanism 402, which is integrated with the intermediary 414, providessubstantially the same functionality as the exemplary transactionmechanisms described above with reference to FIGS. 2 and 3,respectively.

With reference to FIG. 5, an exemplary transactional mechanism 502includes a central processor 504 in communication with other elements ofthe transaction mechanism 502 through a system interface or bus 506. Asuitable display device/input device 508, such as a keyboard or pointingdevice in combination with a monitor, may be provided for receiving datafrom and outputting data to a user. A memory 510 associated with thetransaction mechanism 502 preferably includes a transactional controlmodule 512, a risk management module 514, and an authentication module516. The memory 510 preferably further includes an operating system 518which enables execution by processor 504 of the various softwareapplications residing at transaction control module 512, risk managementcontrol module 514, and authentication module 516. Operating system 518may be any suitable operating system, such as any version of Windows,MacOS, BeOS, Linux, UNIX, and/or the like. Preferably, a networkinterface 520 is provided for suitably interfacing with other elementsof the transaction system, such as the elements described above withreference to FIGS. 2-4. Lastly, a storage device 522, such as a harddisk drive for example, preferably contains suitable files which aresuitably accessed by the transaction control module 512, the riskmanagement module 514, and the authentication module 516.

In particular, customers' transaction records file 524 preferablycomprises transaction information of customers who are registered withthe transaction mechanism 502, which transaction information is used toperform suitable credit risk and fraud risk analyses. Likewise,customers' information records 526 comprises information received eitherfrom a purchaser or a seller upon registration with the transactionmechanism 502 or during the maintenance of the appropriate financialaccount. As used herein, a “customer” may be either a purchaser or aseller who has a financial account with the financial institution whichsuitably maintains the transaction mechanism 502 and who is registeredwith the transaction mechanism 502. Accordingly, providing thetransaction mechanism 502 with access to the appropriate transactionrecords and information records of the parties involved in the fundstransfer facilitates essentially real time risk management by the riskmanagement module 514. Similarly, authentication of the parties to thetransaction may likewise be performed efficiently by the authenticationmodule 516, which preferably has access to the records residing instorage device 522. One skilled in the art will appreciate that thestorage device 522 and, therefore, customer transaction records 524 andcustomer information records 526 may be co-located with the transactionmechanism 502, as illustrated in FIG. 5, or may be remotely located withrespect to the transaction mechanism 502. If the storage device 522 isremotely located with respect to the transaction mechanism 502,communication between storage device 522 and transaction mechanism 502may be accomplished by any suitable communication link but is preferablyaccomplished through a private Intranet or extranet.

Referring next to FIGS. 6 and 7, as discussed, the process flowsdepicted in these figures are exemplary embodiments of the inventiononly and are not intended to limit the scope of the invention asdescribed above. FIG. 6 is a flow diagram representing an exemplaryprocess for facilitating a commercial transaction between a purchaserand a seller. In accordance with the present invention, an exemplaryprocess executed by a suitable transaction mechanism may include any ofthe following: registering a purchaser with the transaction mechanism(step 602); registering a seller with the transaction mechanism (step604); receiving agreed upon transaction terms from at least one of apurchaser and a seller (step 606); receiving a purchaser's selection ofa method for transferring monetary value to a seller (step 608);receiving transaction information from at least one of a purchaser and aseller (step 610); performing authentication, credit risk, and/or fraudrisk analyses (step 612); determining whether the transaction isacceptable (step 614); terminating the transaction if the transaction isnot acceptable; debiting funds from a purchaser's financial account ifthe transaction is acceptable (step 616); holding the funds in an escrowaccount (step 618); releasing the funds from the escrow account anddisbursing the funds to the seller's financial account (step 620); andcrediting the funds to a seller's financial account (step 622).

In accordance with the present invention, any purchaser having afinancial account can transfer funds from the purchaser's financialaccount to the financial account of a second party. For example, apurchaser having a card can transfer funds from the purchaser's card tothe card or demand deposit account of any second party having such anaccount. As represented in FIG. 6 by step 602, the purchaser preferablypre-registers with a transaction mechanism, which transaction mechanismcan be established and maintained by any suitable third party, such as acard issuer, as described above with reference to FIGS. 2 and 3. Toregister with the transaction mechanism, the purchaser may submitsuitable purchaser registration information, such as informationestablishing the identity of the purchaser and information regarding thepurchaser's financial account. The purchaser registration informationcan be suitably stored by the transaction mechanism, such as by storagedevice 522 of FIG. 5. The purchaser may communicate with the transactionmechanism by any means of communication known to those skilled in theart, including communications by telephone or through the use of anyform of computer or point of interaction device having a means forcommunication, such as a modem, suitable wireless means forcommunication, and/or the like. If the transaction mechanism ismaintained by the purchaser's financial institution, the purchaser cansuitably register with the transaction mechanism at the same time thatthe purchaser initially completes the application for the financialaccount. Alternatively, the purchaser can register with the transactionmechanism at any suitable time, including at the time of a transactionwith a seller.

The purchaser registration information which may be used by thetransaction mechanism can include any suitable information, such as anyof the types of information described above with reference to FIG. 2.Upon submission of such information to the transaction mechanism, thetransaction mechanism may then issue to the purchaser a unique useridentifier, such as an identification number, code, password, passphrase, and/or other suitable identifier which may be used by thetransaction mechanism to identify the purchaser. In this manner, thepurchaser's user identifier can be used by the transaction mechanism toidentify and suitably access the purchaser's registration information atthe time of a transaction between a purchaser and a seller. The useridentifier can comprise any number or combination of letters, digits, orother characters. If the transaction mechanism is accessible through theInternet, and especially if the purchaser registers with the transactionmechanism through an interface at an Internet Web page, the transactionmechanism or entity maintaining the transaction mechanism can e-mail theappropriate user identifier to the purchaser, optionally using anywell-known means for secure communications, such as suitable encryption.

As indicated at step 604, the seller preferably also registers with thetransaction mechanism. Although FIG. 6 illustrates the registration of aseller with the transaction mechanism subsequent to the purchaser'sregistration, the seller can register with the transaction mechanism atany suitable time, including prior to the purchaser's registration andat the time of the transaction with the purchaser. As with thepurchaser, the seller preferably provides the transaction mechanism withregistration information to identify the seller and to identify theseller's appropriate financial account, such as a card or a demanddeposit account, to which the transaction mechanism may transfer funds.The seller's registration information may include any suitableinformation, such as the seller's name, location or address, socialsecurity number (if appropriate), federal employer identificationnumber, financial account number, financial institution, and/or anyother suitable information that may be pertinent to a funds transfertransaction. If the seller is associated with the financial institutionthat is providing the transaction mechanism, the seller's registrationinformation can be suitably stored by the storage device shown in FIG.5. Furthermore, as with the purchaser, the seller suitably receives fromthe transaction mechanism a user identifier which identifies the sellerto the transaction mechanism. After the purchaser and seller areregistered with the transaction mechanism, as illustrated in steps 602and 604, the purchaser and seller can suitably agree upon the terms of atransaction, as shown in step 606.

The transaction illustrated in step 606 may be an exchange of goods orservices for value, although this is not required. The transaction, forexample, could include a transaction where the purchaser is gratuitouslytransferring funds from the purchaser's financial account to thefinancial account of the seller, thereby eliminating the need for areciprocal exchange. The purchaser and seller may enter into thetransaction through the Internet, such as where a purchaser seeks topurchase goods, services, or other value from an Internet Web siteoperated by the seller for example. Alternatively, the purchaser andseller can agree to enter into the transaction in a more conventionalmanner, such as through person-to-person communication over thetelephone or in person for example. The particular terms of thetransaction between the purchaser and the seller may include anysuitable terms that are agreeable to the parties and may address issuessuch as the nature of any goods, services, or other value; the amount ofthe funds that are to be transferred from the purchaser's financialaccount to the seller's financial account; the nature and definition ofany escrow release event; the anticipated date or window for delivery orshipment of any goods, services, or other value; and/or other suitableterms and conditions pertaining to the transaction.

After the purchaser and seller have agreed upon the terms of thetransaction, the purchaser may be requested to select a method fortransferring suitable funds to the seller, as indicated in step 608. Theselection of a method for transferring the necessary funds may becompleted through the transaction mechanism or, alternatively, throughany other suitable means and then suitably communicated to thetransaction mechanism. For instance, where the purchaser is purchasinggoods, services, or other value from an online seller via an InternetWeb site, the Web site, rather then the transaction mechanism, canrequest that the purchaser select a method of transferring monetaryvalue to the seller. After the purchaser suitably responds to the query,such as through a pop-up display generated by the Internet site, thepurchaser's response may be suitably communicated to the transactionmechanism. Alternatively, the purchaser can select a funds transfermethod directly through the transaction mechanism, which may occur inthe case where the particular Internet site does not request suchinformation but, rather, allows the transaction mechanism to issue therelevant query. Additionally, the latter circumstance may occur in thecase where a purchaser is transacting with a seller through a site whichmaintains the transaction mechanism, such as an online sales sitemaintained by a card issuer.

In addition to selecting a method for transferring funds to a seller,such as through a card or DDA transaction, the purchaser may also selectone or more value-added services, as indicated in step 608. For example,where the transaction mechanism is maintained by a card issuer, thepurchaser may be able to select value-added services provided by thecard issuer, such as purchaser's insurance, shipping alternatives (wherethe purchaser has purchased goods or, alternatively, services which maybe embodied in documents of any suitable type), postal trackingalternatives, dispute resolution to mediate any dispute that may arisebetween the purchaser and seller regarding the transaction, and/or thelike. It will be appreciated by those of skill in the art thatadditional value-added services may be offered by the seller in additionto those offered by the third party entity maintaining the transactionmechanism.

After selecting a funds transfer method and any value-added services,the purchaser and/or seller may provide suitable transaction informationto the transaction mechanism for authentication, credit risk analysis,and/or fraud risk analysis, as represented in step 610. The transactioninformation can include, but is not limited to, the amount of funds tobe transferred between the purchaser and seller, the date and time ofthe transaction, a description of the transaction, the purchaser's andseller's respective unique user identifiers, and any other pertinentinformation which may suitably identify the transaction as well as boththe purchaser and the seller. For example, the transaction informationcan include a date and time at which the transfer of funds should takeplace. In this manner, the purchaser and seller can indicate that thetransfer of funds can take place at a specific time in the future. Uponreceiving the transaction information, the transaction mechanism canlook-up and access the customer information records, which preferablyinclude at least one of the purchaser's and the seller's registrationand financial account information. As discussed above, this informationpreferably includes data such as the purchaser's financial accountidentifier and/or the seller's financial account identifier, as well asany additional information that has been suitably input in steps 602 and604, above.

Thereafter, as represented by step 612, the transaction mechanism maysuitably determine whether the transaction is acceptable. In anexemplary embodiment, one component of this determination utilizes thetransaction information and the purchaser and/or seller registrationinformation to execute a fraud analysis, as represented by step 614. Forexample, where the transaction mechanism is established and maintainedby a card issuer and the purchaser is a cardholder of a card issued bythe card issuer, the card issuer can maintain a history of thepurchaser's card transactions. Such card transaction history can besuitably stored along with the purchaser registration information in thecustomer information records or the customer transaction records, asdescribed above. Using this historical information, the risk managementmodule of the transaction mechanism can perform a fraud analysis byexecuting a fraud detection program or mechanism to determine whetherthe current transaction, or current transaction in view of recenttransactions, is indicative of fraud. For example, where a card has beenutilized to purchase multiple high-priced items, the fraud analysis mayflag the transaction such that the transaction mechanism will terminateor otherwise not permit the purchaser to complete the transaction. Thefraud detection mechanism may suitably end the transaction, asrepresented by the negative outcome of step 612, or, alternatively, mayquery the purchaser to determine whether the purchaser is actually theproper cardholder. In the case of terminating the transaction withoutpresenting further queries to the purchaser, the purchaser and/or theseller may be contacted through any suitable means, such as a real timedisplay, e-mail, telephone, and/or the like, to notify the purchaserand/or the seller that the transaction was not completed.

The transaction mechanism's determination regarding the acceptability ofthe transaction may suitably include a second component, namely a creditanalysis, as represented by step 615, which effects a comparison of theuser identifiers of either/both the purchaser and the seller with theuser identifiers stored in the storage device to determine whether thetransaction is acceptable. After suitably identifying the accounts ofthe parties entering into the transaction, the transaction mechanism maysuitably analyze whether the transaction is acceptable based uponadditional criteria. The analysis for determining transactionacceptability can be suitably implemented through a computer-readablestorage medium encoded with processing instructions, as described above.Such analysis can include a determination of whether the purchaser hassufficient credit or funds in the financial account to complete thetransaction. Additionally, in the event that the purchaser uses a cardto accomplish the funds transfer to the seller, the transactionmechanism may suitably terminate the transaction if it determines thatthe purchaser's card has expired, has been reported as lost or stolen,or is otherwise invalid. Where the transaction mechanism determines,through a program or any other suitable means, that the transactioncannot be completed properly, the transaction mechanism will notcomplete the transaction, as seen in the negative outcome of step 612.When a negative outcome occurs, the purchaser and/or the seller may becontacted through any suitable means, such as a real time display,email, telephone, and/or the like, to notify the purchaser and/or theseller that the transaction was not completed and to provide particularreasons for the termination of the transaction.

Once a transaction is deemed to be acceptable, the transaction mechanismsuitably completes the transaction by debiting the purchaser's financialaccount, as represented by step 616. Preferably, the transactionmechanism then transfers the funds to a suitable escrow account andholds the funds in the escrow account until a suitable escrow releaseevent has transpired, as represented by step 618. Once the escrowrelease event has transpired, the funds are then released from theescrow account and disbursed to the seller's financial account, asrepresented by step 620. In accordance with the terms of the transactionas agreed to by the purchaser and the seller, the funds then aredisbursed to the seller's financial account and the seller's account issuitably credited with the funds, as represented by step 622. Thetransaction mechanism may automatically include any suitable transactionfees, as a service charge for the transaction, in the funds debited fromthe purchaser's financial account and/or may automatically deduct suchfees from the funds disbursed to the seller's financial account.

FIG. 7 is a flow diagram of the operation of an exemplary transactionmechanism in accordance with the present invention. As described abovewith reference to FIG. 6, the transaction mechanism preferably firstreceives registration information from the purchaser and the seller, asindicated by steps 702 and 704. Registration information may be enteredby a purchaser and/or a seller using any well-known input device, suchas a keyboard or mouse suitably connected to any type of computer whichcan suitably communicate with the transaction mechanism. Theregistration information may then be transmitted to the transactionmechanism either in real time or downloaded to the transaction mechanismafter the registration information is input by the purchaser and/or theseller.

Optionally, as is shown in step 706, the transaction mechanism mayreceive an indication that a transaction between a purchaser and aseller has been initiated. This indication may originate from either thepurchaser or the seller or, alternatively, from an intermediary, whichmay be unrelated to the entity which maintains the transactionmechanism. For example, a purchaser may choose to transfer funds usingan interface located at an intermediary's Web site. This type of fundstransfer might occur after the intermediary has suitably queried thepurchaser as to the purchaser's preferred funds transfer method, such asby issuing a query by using any of several conventional graphicalinterfaces or pop-up graphics that are well-known in the art.Alternatively, the seller may suitably initiate the transaction.

Thereafter, as represented by step 708, the transaction mechanismreceives suitable information regarding the purchaser's selected methodfor transferring funds to the seller, such as by a card or DDA forexample, and any selected value-added services, as described above. Thisstep may be facilitated by any suitable mechanism, such as a suitablenetwork connection, such as an Internet connection, or through anysuitable input device associated with the transaction mechanism.Preferably, at least one of the purchaser and the seller providessuitable transaction information to the transaction mechanism forauthentication, credit risk, and fraud risk analyses. Once thetransaction mechanism receives suitable transaction information, asrepresented by step 710 and as described in greater detail above, thetransaction mechanism suitably determines whether the transaction isacceptable, as represented by step 712. The fraud detection mechanismexecuted by the risk management module of the transaction mechanism thensuitably communicates with the customer transaction records and customerinformation records to determine whether the transaction represents apotential fraud risk, as represented by step 714 and as described ingreater detail above with reference to FIG. 6.

After the fraud detection mechanism has been executed, the transactionmechanism may then suitably perform a credit analysis, as represented bystep 715, to compare the user identifiers of either/both the purchaserand the seller to the user identifiers stored in the storage device inan additional effort to determine whether the transaction is acceptable.As described above with reference to FIG. 6, after suitably identifyingthe accounts of the parties entering into the transaction, thetransaction mechanism also may suitably determine whether the purchaserhas sufficient credit or funds in the financial account to complete thetransaction. Additionally, in the case that the purchaser uses a card toeffect the funds transfer to the seller, the analysis can furtherinclude a determination of whether the card has expired, has beenreported as lost or stolen, or is otherwise invalid. Where thetransaction mechanism determines, through a program or any othersuitable means, that the transaction cannot be completed properly, thetransaction mechanism will not complete the transaction, as seen in thenegative outcome of step 712. When a negative outcome occurs, thepurchaser and/or seller may be contacted through any suitable means,such as a real time display, e-mail, telephone, and/or the like, tonotify the purchaser and/or the seller that the transaction was notcompleted and to provide particular reasons for the termination of thetransaction.

Once the transaction is deemed acceptable, the transaction mechanismcompletes the transaction by debiting the purchaser's account, asrepresented by step 716. Preferably, the transaction mechanism thentransfers the funds to a suitable escrow account and holds the funds inthe escrow account until a suitable escrow release event has transpired,as represented by step 718. Once the transaction mechanism receivesinformation indicating that the escrow release event has transpired, asrepresented in step 720, the funds are then released from the escrowaccount and disbursed to the seller's financial account, as representedby step 722. The transaction mechanism also may automatically accountfor any suitable transaction fees, as a service charge for thetransaction, by suitably including any such fees in the funds debitedfrom the purchaser's financial account and/or by suitably deducting anysuch frees from the funds disbursed to the seller's financial account.

Referring now to FIG. 8, another exemplary embodiment of the presentinvention includes an auction intermediary 814, such as eBay, and ashipping service 816, such as Federal Express®, United Parcel Service®,and/or any other suitable shipping service. In this embodiment, theseller 806 and/or the purchaser 804 initially register with thetransaction mechanism 802. Preferably, the seller 806 lists goods forsale at the Web portal provided by the auction intermediary 814, whichlisting results in a bid on the goods submitted by a purchaser. Theauction intermediary 814 then determines who has submitted the highestbid and notifies both the high-bidding purchaser and the seller. Thepurchaser 804 then selects a method for transferring suitable funds tothe seller, such as by a suitable transaction card or DDA. At the timeof the transaction, the purchaser may also be presented with the optionof selecting one or more value-added services. The purchaser transactioninformation is then suitably transmitted to the transaction mechanism802. Likewise, the seller suitably provides the transaction mechanism802 with suitable seller information for authentication purposes. Thetransaction mechanism 802 then performs suitable risk managementanalysis to determine whether the proposed transaction is associatedwith any credit and/or fraud risks. If the purchaser 804 has sufficientfunds available to complete the transfer and if both the purchaser 804and the seller 806 are authenticated (and assuming that the credit andfraud risk analyses do not result in a negative determination), then thetransaction mechanism 802 suitably debits the purchaser's card or DDA bythe amount of the purchase price as well as the cost of any selectedvalue added services. The transaction mechanism 802 then sends aconfirmation to the seller 806 that the purchaser's account has beendebited. Preferably, the transaction amount then is suitably held in anescrow account maintained by the transaction mechanism, and once theshipping service 816 acquires the goods from the seller for shipment tothe purchaser, the transaction mechanism 802 receives a tracking numberfrom the shipping service 816. Depending upon the nature of the escrow,the transfer of funds to the seller's card or DDA will be delayedaccordingly. For example, the escrow may be based upon a 3-day waitingperiod following notification to the transaction mechanism 802 of thereceipt of the goods by the purchaser 804, which notification may bereceived directly from the purchaser 804 or from the shipping service816. Accordingly, the transaction mechanism 802 disburses theappropriate funds to the seller's DDA (minus any transactional fee) atthe seller's bank, which suitably credits the funds to the seller'sfinancial account. If selected by either the purchaser or the seller,value-added services, such as purchaser's insurance and disputeresolution, may be provided as needed. The systems and methods fordispute resolution may include, for example, U.S. Pat. No. 7,249,113issued on Jul. 24, 2007 “System And Method For Facilitating The HandlingOf A Dispute,” which is hereby incorporated by reference in itsentirety.

As will be appreciated by one skilled in the art, the present inventionadmits of various aspects which may be implemented in any of severalways. FIGS. 9-20 illustrate the flow of an exemplary transactionimplemented in accordance with particular aspects of the presentinvention. However, it should be understood that this transaction flowis exemplary only and is not intended to limit the scope of the presentinvention as described above.

With reference to FIG. 9, an exemplary user registration process 902begins when an individual 904, such as an Internet user, accesses thetransaction mechanism and requests registration with the transactionmechanism. Internet user 904 may be either a potential purchaser or apotential seller. As illustrated in the exemplary interface of FIG. 10,an Internet user may suitably register with the transaction mechanism byactivating hyperlink 1002, which activation preferably results in thedisplay of the terms and conditions for registration and a request thatan Internet user input suitable registration information, as describedin greater detail above.

Once an Internet user 904 has registered with the transaction mechanism,the Internet user 904 may then suitably request to be logged into thetransaction system, as represented by step 906 of FIG. 9. As illustratedin the exemplary transaction mechanism main page of FIG. 11, an Internetuser may suitably request the login page by activating hyperlink 1102,which activation preferably results in the display of a login pagehaving suitable datafields. The datafields may request any suitablelogin information from an Internet user. Such login information mayinclude, for example, a request for the Internet user's unique useridentifier and a password or pass phrase. Once the Internet user submitsthe requested information, the Internet user is suitably logged into thetransaction system. If the Internet user submits an invalid useridentifier and/or password, an error message is suitably displayed, andthe Internet user is requested to re-enter and re-submit theinformation. Once the Internet user is logged into the transactionsystem, the transaction system retrieves the list of registered card andDDA accounts held by the Internet user and displays a suitableinterface, such as the exemplary interface of FIG. 12, which may provideany suitable means for either conveying information to or receivinginformation from the Internet user. As illustrated in the exemplaryembodiment represented in FIG. 12, the transaction system preferablyprovides means for initiating a transaction, such as tab 1202 forexample, and may suitably display the Internet user's transactionhistory, as represented by data table 1204. Suitable data accessoptions, such as hyperlinks 1206 and 1208, may be provided to enable theInternet user to access any suitable information that may be provided bythe transaction system, such as information pertaining to otherregistered financial accounts and/or means for registering additionalfinancial accounts with the transaction mechanism.

With momentary reference to FIG. 9, in an exemplary embodiment, Internetuser 904 may be either a seller 908 or a purchaser 910. If Internet user904 is a seller 908 who is suitably registered and logged into thetransaction system, the seller 908 may suitably initiate a transactionthrough the transaction mechanism. In an exemplary embodiment, there arepreferably two aspects involved in a seller-initiated transaction.First, the seller 908 suitably creates a transaction invoice, asrepresented by step 912. Then, the purchaser 910 preferably confirms oraccepts the transaction, as represented by step 914. Preferably, at anygiven point during the transaction, either the seller 908 or thepurchaser 910 may either cancel (step 916) or reverse (step 918) thetransaction. In the event that a purchaser 910 or a seller 908experiences any difficulty with the transaction mechanism or if there isa dispute between the seller 908 and the purchaser 910, a customerservice representative 920 associated with the third party entity whichis providing the transaction mechanism may suitably provide any desiredcustomer service and/or dispute resolution (step 922).

FIG. 13 next illustrates an exemplary process for initiating acommercial transaction between a seller and a purchaser. In thisexemplary embodiment, a seller-initiated transaction preferably beginswhen the seller submits a request to start a transaction, such as byactivating tab 1202 of FIG. 12. Once the transaction mechanism receivesthe request, the transaction mechanism determines whether the seller isa registered user (step 1304). If the seller is not a registered user,the transaction mechanism provides a suitable registration interface(step 1306), such as described above with reference to FIG. 10. If theseller is a registered user, the transaction mechanism provides asuitable means for initiating the transaction (step 1308), such as byproviding the exemplary interface of FIG. 14.

The seller then suitably provides the information requested by thetransaction mechanism (step 1310). For example, the seller enters theappropriate information which may be requested by various transactiondatafields provided by the transaction mechanism through a suitable userinterface, such as the exemplary transaction invoice entry page 1400 ofFIG. 14. The transaction datafields provided by a suitable transactionentry interface may include suitable datafields of any number or form,such as, for example, a datafield 1402 for a prospective purchaser'semail address; a datafield 1404 indicating a final date for theacceptable transfer of funds to the seller; a datafield 1406 forindicating the seller's reference number; a datafield 1408 for atransaction description, such as the identification of any intermediary,like eBay, which may be involved in the transaction; datafields 1410 fora description of the particular items that will be the subject of thetransaction; datafields 1412 for indicating the appropriate quantity ofeach item described in datafield 1410; datafields 1414 for indicatingthe appropriate price for each item described in datafield 1410;datafields 1416 for indicating the subtotal amount or extended priceassociated with the quantity and price for each item described indatafield 1410; a datafield 1418 for indicating a suitable cost for anydesired value-added services, such as insurance, dispute resolution,postal tracking, or any other suitable value-added service; a datafield1420 for indicating the cost associated with any shipping and handlingcharges; datafield 1422 for indicating any miscellaneous charges thatmay be associated with the transaction, such as any applicable taxes forexample; and a datafield 1424 for indicating a total charge or totalamount of funds to be transferred from the purchaser to the seller uponcompletion of the transaction. Additional information that may berequested from the Internet user may include the email address of theInternet user, any optional email message intended for the purchaser,and/or any other suitable information.

Additionally, a suitable transaction entry interface may include anynumber or form of tabs, such as tab 1426 which activates the creation ofadditional datafields 1410. The additional tab or tabs may be used bythe seller to activate or implement any suitable function which mayfurther facilitate the transaction between the seller and the purchaser.For example, transaction invoice entry page 1400 may also include anadditional datafield, or tab for accessing an additional datafield,which may request that the seller provide suitable information regardingan escrow release event. Such escrow release event information mayinclude a particular time period within which a purchaser may eitheraccept or reject any items prior to the transfer of funds from theescrow account to the seller's account, such as a particular number ofdays after the purchaser receives goods, services, or other value from asuitable shipping agent.

In addition to entering the appropriate information which may berequested by the various transaction datafields provided by thetransaction mechanism, the seller preferably is further requested toselect a suitable financial account which will ultimately receive thefunds transferred from the purchaser at the completion of thetransaction. Preferably, the various options presented to the seller onthe transaction entry interface reflect the financial account oraccounts provided by the seller during the seller's registration withthe transaction mechanism, as described above. The financial accountselection options may include any suitable selection options whichprovide the transaction mechanism with the appropriate information. Asillustrated in exemplary transaction invoice entry page 1400, financialaccount selection options may include selection options 1428 and 1430which preferably indicate the type of financial account 1428, such as acredit card or a demand deposit account (DDA), and the financial accountidentifier 1430, such as a credit card number or a DDA number.

As one skilled in the art will appreciate, the above describedtransaction entry interface, as well as any or all other aspects of thepresent invention, may include any suitable form of encryption and/orother security measures either currently known or hereafter devised.

Once the seller completes a suitable transaction entry interface, theseller may either submit or cancel the transaction invoice entry (step1312). If the seller cancels the transaction invoice entry, such as byactivating tab 1432 of FIG. 14, the seller is returned to thetransaction mechanism main page (step 1314), such as the exemplarytransaction mechanism main page illustrated in FIG. 11. If the sellersubmits the transaction invoice entry page to the transaction mechanismby activating, for example, a suitable tab, such as tab 1432, or bypressing the enter key on a suitable input device, a transaction invoiceis then displayed by the transaction mechanism (step 1316). Thetransaction invoice may include any suitable information entered by theseller on the transaction entry interface and any other relevantinformation, such as any transaction or service fees charged by thetransaction mechanism. As illustrated in the exemplary transactioninvoice 1500 of FIG. 15, such information may include any or all of theentries corresponding to the datafields described above with referenceto FIG. 14. In addition, the transaction invoice may include an invoicenumber 1536 which may be automatically assigned by the transactionmechanism; an additional service fee amount 1538 which may be suitablydeducted from the amount of funds transferred from the purchaser; atotal amount 1540, net of fees, owed to the seller at the completion ofthe transaction; the date 1542 that the transaction invoice was created;and a status indicator 1544, which may include any suitable indicator ofany suitable status that may be relevant to the transaction as of thedisplay date of the transaction invoice, such as any of the exemplarystatus indicators illustrated beneath status key 1546 (i.e., paid,waiting on purchaser, declined by purchaser, and expired).

After the seller completes a review of the transaction invoice, theseller may either decline or accept the transaction invoice (step 1318).If the seller declines the transaction invoice, such as by suitablyactivating tab 1548 of FIG. 15 for example, a suitable transactioninterface is displayed (step 1319), such as exemplary cancel transactionpage 1600 of FIG. 16, which may provide suitable means, such as tabs1602 and 1604, for either initiating a new transaction or returning tothe transaction mechanism main page. If the seller accepts thetransaction invoice, such as by suitably activating tab 1550 of FIG. 15or pressing the enter key on a suitable input device for example, thetransaction invoice is suitably stored by the transaction mechanism in asuitable storage device (step 1320). Then, the transaction invoice ispreferably transmitted to both the purchaser and the seller by anysuitable method, such as by email, facsimile, mail, and/or the like(step 1322). Preferably, the transaction invoice is transmitted viaemail to the respective email addresses of the purchaser and the seller.

Once the seller's transaction invoice is transmitted to the purchaser,the transaction may be suitably completed when the purchaser accepts thetransaction. In the exemplary embodiment illustrated by the flowchart ofFIG. 17, when the purchaser receives a transmission from the transactionmechanism regarding the transaction invoice (step 1702), such as anemail transmission having a hyperlink to a suitable purchasertransaction interface, the purchaser may follow the link to thetransaction interface (step 1704), such as the exemplary purchasertransaction review page 1800 of FIG. 18, to review the terms andconditions of the transaction as set forth by the seller. As illustratedin FIG. 17, a purchaser may accept a transaction by one of at leastthree methods, wherein the methods are indicated by phantom lines torepresent the purchaser's optional courses of action. First, thepurchaser may accept the transaction using a suitable card withoutlogging into the transaction system (step 1706). Second, the purchasermay accept the transaction by suitably logging into the transactionsystem and selecting a suitable card to transfer funds to the seller(step 1708). Finally, the purchaser may accept the transaction bysuitably logging into the transaction system and selecting a suitableDDA to transfer funds to the seller (step 1710).

In the first case, the purchaser accepts the transaction with a suitablecard without logging into the transaction system. If the transactionterms and conditions are acceptable to the purchaser, the purchasersuitably completes the purchaser transaction review page (step 1706) byproviding information regarding the purchaser's card to effect asuitable transfer of funds from the purchaser's card account to thefinancial account of the seller. As illustrated in exemplary purchasertransaction review page 1800 of FIG. 18, the purchaser enters theappropriate information which may be requested by various transactiondatafields provided by the transaction mechanism on the purchasertransaction review page 1800. The transaction datafields provided by thepurchaser transaction review page may include suitable datafields of anynumber or form, such as, for example, a datafield 1802 for thepurchaser's name as it appears on the card; a datafield 1804 forindicating a card account number; a datafield 1806 for providing a cardidentification number, such as the four digits that are frequentlyprinted on the card above the card number; and datafields 1808 forindicating the card's expiration date.

Additionally, purchaser transaction review page 1800 may include anynumber or form of additional tabs or datafields. The additional tabs ordatafields may be used by the purchaser to implement any suitablefunction which may further facilitate the transaction between the sellerand the purchaser. For example, purchaser transaction review page 1800may also include an additional datafield, or tab for accessing anadditional datafield, which may permit the purchaser to provide ormodify information regarding an escrow release event. Such escrowrelease event information may include a particular time period withinwhich a purchaser may either accept or reject any items prior to thetransfer of funds from the escrow account to the seller's account, suchas a particular number of days after the purchaser receives goods,services, or other value from a suitable shipping agent. If a purchasermodifies or adds information to the purchaser transaction review page,such as modifying or adding information regarding an escrow releaseevent, the transaction flow as described herein preferably includes anadditional communication or transmission of the transaction terms to theseller so that the seller is given a suitable opportunity to eitheraccept or decline the modified terms and conditions of the transaction.

After the purchaser has suitably entered the requested information, thepurchaser suitably submits the purchaser transaction review page to thetransaction mechanism, such as by activating tab 1810 or pressing theenter key on a suitable input device for example. Once the purchaser'scard information profile has been completed and the purchasertransaction review page is submitted, the transaction mechanism displaysa suitable transaction invoice, such as exemplary purchaser transactioninvoice 1900 of FIGS. 19A and 19B. At this point, the purchaser mayeither accept or decline the transaction (step 1712). If the purchaserdeclines the transaction, such as by suitably activating tab 1902 ofexemplary purchaser transaction invoice 1900, a suitable interface isdisplayed (step 1714), such as exemplary purchaser decline transactionpage 2000 of FIG. 20, which may provide any suitable information ormeans for acquiring information, such as tabs 2002 and 2004.

If the purchaser accepts the transaction, the transaction mechanismperforms a suitable card authorization/authentication routine, which mayinclude suitable credit risk and fraud risk analyses (step 1716). If thetransaction is unacceptable, either due to a potential fraud risk or acredit risk, the transaction mechanism cancels the transaction andsuitably notifies, such as by email, both the purchaser and the seller(step 1718). If the transaction is acceptable, the transaction mechanismsuitably debits the purchaser's account. Preferably, the transactionmechanism then credits an appropriate escrow account (step 1720),pending notification by either the purchaser and/or a shipping agentthat any defined escrow release event has transpired (step 1722). If thedefined escrow release event transpires, the transaction mechanismsuitably disburses the appropriate funds to the seller's financialaccount (step 1726) and notifies both the purchaser and the seller thatthe transaction has been completed (step 1728). However, if an escrowrelease event has been defined during the transaction by either thetransacting parties or a suitable third party and the escrow releaseevent is not satisfied, the transaction mechanism either reverses thetransaction, such as by performing a suitable chargeback or some othersuitable transaction reversal procedure, or follows a suitable disputeresolution protocol, as described above (step 1724). As illustrated inphantom lines in order to represent alternative process flows, if anydispute between the parties is favorably resolved, suitable funds may bedisbursed to the seller (step 1726) and the parties may be notified ofthe completion of the transaction (step 1728). However, if any disputeis not favorably resolved, or if the most appropriate resolution iscancellation of the transaction, the transaction is suitably terminatedor otherwise reversed, and the purchaser and seller are suitablynotified of the termination and/or reversal of the transaction (step1728).

In the second case, the purchaser accepts the transaction by logginginto the transaction system and selecting the option of transferringfunds to the seller from the purchaser's card (step 1708).Alternatively, the purchaser accepts the transaction by logging into thetransaction system and selecting the option of transferring funds to theseller from the purchaser's DDA (step 1710). In either of thesesituations, the transaction mechanism suitably processes the purchaser'slogin request and determines whether the purchaser is a registered user(step 1730). If the purchaser is not a registered user, the transactionmechanism provides a suitable registration interface (step 1732), suchas described above with reference to FIG. 10. If the purchaser is aregistered user, the transaction mechanism then performs steps 1712through 1728, as described above.

Although the exemplary embodiments described herein may disclose anexemplary seller-initiated transaction, one skilled in the art willappreciate that the present invention is not so limited and may bereadily implemented by means of any suitable purchaser-initiatedtransaction and/or any suitable third-party-initiated transaction, suchas an intermediary-initiated transaction.

The present invention contemplates any type of transfer between, or atransaction involving, accounts (e.g., financial accounts). In oneembodiment, any such transfers and/or transactions are partially orfully facilitated by a processor. The financial accounts may be owned,controlled or utilized by the same person, different people, relatedpeople, employers and employees, corporations or other entities,charities and/or the like. As set forth above, each of the accounts maybe issued by the same or different processors (e.g., Account A is a Visaaccount and Account B is an American Express account) and/or processedby the same or different processors. A “processor” may include anyentity which processes transactions, issues accounts (e.g., transactionaccount issuer), acquires financial information, settles accounts,conducts dispute resolution regarding accounts, and/or the like. Forexample, a processor may provide data transfer capabilities thattransfer data from a customer at a point-of-sale (POS) terminal orinternet website to the transaction account issuer and then back to thePOS terminal or internet website. The processor, intermediary, and/oraccount holders may communicate by any device, method or technologydiscussed herein such as, for example, via internet, cellular phone,personal digital assistant, radio frequency (RFID), infrared and/or thelike.

The account code may be distributed and stored in any form of plastic,electronic, magnetic, radio frequency, wireless, audio and/or opticaldevice capable of transmitting or downloading data from itself to asecond device. A customer account number may be, for example, asixteen-digit credit/charge card number, although each credit providerhas its own numbering system, such as the fifteen-digit numbering systemused by American Express. Each issuer's transaction account numberscomply with that company's standardized format such that the companyusing a fifteen-digit format will generally use three-spaced sets ofnumbers, as represented by the number “0000 000000 00000”. The firstfive to seven digits are reserved for processing purposes and identifythe issuing bank, card type, etc. In this example, the last (fifteenth)digit is used as a sum check for the fifteen digit number. Theintermediary eight-to-eleven digits are used to uniquely identify thecustomer. A merchant account code or an account number for any partydiscussed herein may be, for example, any number or alpha-numericcharacters that identify a particular merchant for purposes of cardacceptance, account reconciliation, reporting, or the like.

The transfers discussed herein may be related to a purchase transaction,an exchange of an item (e.g., good, service, information, experience,access, entertainment, etc), no item exchange, a loan to another account(e.g., debiting a loan amount from a first account and charging a loanamount to a second account), transferring credit to another account,cost splitting, budgeting, spend compartmentalization, gifting, currencyexchanges, currency exchange rates, loyalty points, monetaryequivalents, non-monetary items and/or the like. Various notificationsmay be provided by any party discussed herein, using any technologydiscussed herein, and/or in association with any action or non-actiondiscussed herein. The transaction may include a registration process forone or more parties, compliance with additional terms and conditions(which may be set by any party discussed herein), tracking any portionof the process, and/or a credit, qualifying or other fraud/securityanalysis.

In one embodiment, the transaction may not involve the exchange of anyitems. The transfer may be between accounts owned or controlled by thesame entity or person for the purposes of cost splitting, budgeting, andspend compartmentalization. In one embodiment, an account holder mayapportion certain charges, rebates, credits, credit limits, availablecredit, etc among various accounts. For example, an account holder maydesire to transfer college expenses to a first account, businessexpenses to a second account and personal expenses to a third account.If an account holder owns two businesses, the account holder may dividea charge for a printer among a first account associated with a firstbusiness and a second account associated with a second business. Inanother embodiment, a first and second account holder may attend adinner, yet a first account holder charges the dinner to her account.The first account holder can then split the cost of the dinner bytransferring, using the methods discussed herein, any portion of thedinner charge to the account of the second account holder. The costsplitting may occur upon authorization of the charge, submission of thecharge, settlement of the charge, or any time subsequent to the firstaccount holder incurring the charge. The cost splitting may also bepre-arranged such that a rule is set to automatically transfer a portionof the charge to the first account to the second account (e.g., when atwo person sales team often entertains clients).

The transaction may involve crediting an account; offsetting a charge onan account; reducing an amount owed on an account; increasing ordecreasing a credit limit; increasing or decreasing an availablebalance; increasing or decreasing a feature; increasing, decreasing,removing or implementing a restriction or limitation; charging intereston any amount of feature discussed herein; charging or deducting atransaction fee; and/or changing a feature or charge for a second partybased upon payment of a charge by a first party.

Such increases of a credit limit, etc may include increasing a creditlimit by an amount greater than, equal to or less than the correspondingdecrease. The credit, debit, increase or decrease may also occur in realtime, batch mode, at a predetermined time or random time. An exemplarysystem and method for adjusting a credit limit or available funds isdisclosed in U.S. Pat. No. 6,796,497, issued on Sep. 28, 2004 andentitled “System And Method For Facilitating A Subsidiary Card Account,”which is hereby incorporated by reference.

The following is an example of converting a charge to credit (for asecond party based upon payment of a charge by a first party), using thepresent invention. A first party having a Visa account may transfer $50from the Visa account to an American Express account of a second party.The Visa account is charged $50 and the American Express account iscredited $50. The next billing statement for the Visa account will showa $50 charge for which the first party needs to remit a payment. Priorto the first party remitting payment to Visa to pay for the charge,American Express may increase the available credit (or increase thecredit limit) on the second party's American Express account. Increasingthe available credit is a precautionary measure in that it will allowthe second party to incur charges for an additional $50, but the secondparty is still incurring those charges based on the second party'screditworthiness with American Express. However, after the first partyremits payment to Visa, then Visa will be able to settle the $50 withAmerican Express. Because American Express now obtained the $50 of fundsfrom Visa, American Express converts the $50 increase of availablecredit to a $50 credit on the second party's account. If the secondparty does not partially or fully use the $50 credit for a period oftime, then American Express may provide interest on the $50 and depositthe interest into the second party's account as additional credit (ordeposit the interest into any other account, e.g., savings account,etc).

The accounts may include a transaction card account, an escrow account,a digital cash account, a demand deposit account, a credit line, a lineof credit, checking account, savings account, a gift card account, apre-paid account, a credit union account, a bank account, an investmentaccount, and/or a money market account. The financial account processormay include a transaction account issuer, charge card issuer, creditcard issuer, debit card issuer, gift card issuer, bank, lender, creditunion, and/or a third party issuer under contract with the financialaccount issuer.

Any of the account codes or account identifiers discussed herein mayinclude single-use, temporary, proxy, limited-use, restricted,pre-authorized, partial authorized and/or other types of account codesor transaction accounts, and/or identifiers selected from a pool ofaccount numbers, identifiers associated with manual overrideauthorizations. For example, the present invention contemplates usingthe methods, systems, account codes and/or transaction accountsdiscussed in U.S. patent application Ser. No. 10/711,827 filed on Oct.7, 2004 and entitled “Limited Use Pin System And Method”; U.S. patentapplication Ser. No. 09/906,456 filed on Jul. 16, 2001 and entitled“Method And System For Facilitating The Anonymous Purchase Of Goods AndServices From An E-Commerce Website”; and U.S. patent application Ser.No. 09/800,461 filed Mar. 7, 2001 and entitled “System for Facilitatinga Transaction”; U.S. Pat. No. 6,901,387 issued on May 31, 2005 andentitled “Electronic Purchasing Method And Apparatus For Performing TheSame”; U.S. patent application Ser. No. 10/391,689 filed on Mar. 19,2003 and entitled “Methods and System for Facilitating a Transaction”;U.S. patent application Ser. No. 10/724,940 filed on Dec. 1, 2003 andentitled “Method and System for Completing Transactions InvolvingPartial Shipments”; U.S. patent application Ser. No. 10/801,765 filed onMar. 16, 2004 and entitled “Method and System for Manual Authorization”;U.S. Pat. No. 5,991,750 issued on Nov. 23, 1999 and entitled “System andMethod for Pre-Authorization of Individual Account Transactions”, and,U.S. Pat. No. 6,796,497 issued Sep. 28, 2004 and entitled “System AndMethod For Facilitating A Subsidiary Card Account,” all of which arehereby incorporated by reference in their entirety.

In one embodiment, any of the accounts discussed herein may also includea flexible limit subsidiary card account. In particular, the account mayallow a parent to provide funds to a subsidiary and to at leastpartially control the subsidiary's spending capacity. The system foradministering a subsidiary card account includes a parent and anadministrator. The parent, which is responsible for a related creditinstrument, e.g., a parent account, is configured to communicate arequest for a credit card account to be issued to a subsidiary. Theadministrator is configured to receive the request from the parent andto facilitate the establishment and issuance of the subsidiary cardaccount. The administrator is also configured to facilitatedetermination and adjustment of appropriate spending power for theparent account and spending capacity for the subsidiary card account inaccordance with a predetermined set of rules. An exemplary set of rulesmay require an allocation of risk between the administrator and theparent whereby the spending power of the parent account is reduced by anamount that is less than the credit line established for the relatedsubsidiary card account, in accordance with an allocation of risk to theadministrator. In addition, an exemplary administrator is furtherconfigured to receive and facilitate execution of a request from theparent to define, modify, and/or terminate the spending and/or debtaccumulation limits, i.e., capacities, for the subsidiary card account.

In another embodiment, any of the accounts discussed herein may also beassociated with a proxy account number. The account holder may obtain asecondary transaction number that is associated with a cardholder'sprimary account, (e.g., charge card), wherein the cardholder presents ortransmits the transaction number—not the primary charge card number—tothe merchant to initiate a transaction.

More particularly, the system involves the process of registering acardholder (if not already pre-registered) to participate in atransaction system; generating a secondary transaction number andissuing this number to the cardholder, where the cardholder presentsthis number to another party or intermediary (e.g., to complete atransaction); the transaction mechanism processes this secondarytransaction number, similar to any other credit card number, where thenumber is typically presented to the credit card provider forauthorization. Throughout this process, the cardholder's primary chargecard number is never passed to the merchant or any other third party.Additionally, the secondary transaction number may also carry with itcertain limitations-on-use conditions, where the transaction is notauthorized unless these conditions are met.

In generating a secondary transaction number, upon a cardholder'srequest, the card provider generates a random number and associates thisnumber with the cardholder's primary charge card account. Thisinstantaneous and immediate generation of a random number allows for thenumber to be used by the cardholder immediately upon receipt. Thisprocess obviates the need for separate activation of the secondarytransaction number, and minimizes the possibility that a secondarytransaction number, once issued, will not be utilized because thecardholder or card provider failed to “activate” it. During theauthorization phase of the transaction process, the issuer (e.g.,transaction mechanism) receives the authorization request and verifiesthat certain limitations-on-use conditions, if any, have been satisfied.If the conditions have been satisfied, the request is approved and theissuer sends the merchant an approval code. If conditions have not beenmet, the request is declined. Although the request is declined, in anexemplary embodiment, the secondary transaction number is not“deactivated,” and, as a result, may still continue through the paymentprocess. An exemplary settlement process of the present inventioninvolves receiving a request from a merchant to be paid for a particulartransaction and paying the merchant. As noted above, even a secondarytransaction number that has not been authorized or that has been deniedauthorization by the issuer, may proceed through settlement, with theincumbent risk to the payee that the transaction (if not accompanied bya valid approval code) may later be charged back to the payee if thetransaction is ever disputed. During the settlement process, theaccounts payable system pays the payee (intermediary, second party,etc), referencing only the secondary transaction number. However, priorto the accounts receivable processing, the secondary transaction numberis replaced with the primary account for cardholder billing. The accountholder's statement may reflect, as desired, the secondary transactioncode(s), the primary account code(s), all codes or any combination ofthese codes.

The dispute handling and customer service processes of an exemplaryembodiment of this invention enable customer service representatives toretrieve information and initiate customer or merchant inquiries basedon the primary account number, the secondary transaction number or othertransaction specific information provided by either the cardholder orthe merchant. Therefore, the account holder may provide either theprimary account number or the secondary transaction number to thecustomer service representative to initiate a dispute. With eithernumber, the representative is able to look-up the associated accountnumber and account information. The system provides seamless integrationof the secondary transaction number and the primary account (i.e.,charge card) number to ensure that the payee only sees statements,reports, letters, or financial adjustments bearing the secondarytransaction number—not the charge card number, while the account holderneed only reference the primary charge card account. Additionally, it isthrough the dispute handling process that the account holder may disputea transaction involving, inter alia, an unauthorized use of thesecondary transaction number and it is during this process that thetransaction amount is charged back to the payee. Other situationsinvolving a payee charge-back may include duplicate billing; service oritem not received; item returned; or wrong amount billed.

In another embodiment, any of the accounts discussed herein may also beassociated with a limited use account or PIN. In this regard, thepresent invention facilitates transactions between a first party and asecond party by providing the user with a limited use PIN that isassociated with a user's primary account and/or PIN number, wherein theuser presents or transmits the limited use PIN to the second party,intermediary or the transaction mechanism to initiate a transaction. Thetransaction processor may process this limited use PIN, similar to anyother PIN, where the number is typically presented to the credit issuerto facilitate authorization. Throughout this process, the user's primarycharge account number and/or PIN may never be passed to the secondparty, intermediary or any other third party. Additionally, the limiteduse PIN may also carry with it certain limitations-on-use conditions,where the transaction is not authorized unless these conditions are met.In generating a limited use PIN, which may be upon a user's request, theissuer may generate a random number and associates this number with theuser's primary charge account.

In another embodiment, any of the accounts discussed herein may also beassociated with a plurality of transaction account numbers, wherein eachof the transaction account numbers is associated with a monetary loadvalue. In one embodiment, the transaction account numbers are stored ina database which has a plurality of records. Each record corresponds toone of the transaction account numbers. None of the records isconfigured to store identifying information of a purchaser of one of thetransaction numbers. A request for an authorization of a purchasetransaction having a purchase value is received from a remote computerterminal, wherein the request is associated with one of the transactionaccount numbers. The method further includes comparing the purchasevalue to the monetary load value associated with the transaction accountnumber to determine if the purchase value exceeds the monetary loadvalue. The method further includes authorizing the request for anauthorization of a purchase transaction. The purchase value is thensubtracted from the monetary load value associated with the transactionaccount number to obtain an updated monetary load value. The updatedmonetary load value is then associated with the transaction accountnumber.

The presently claimed invention may also incorporate features of adigital wallet as set forth in, for example, U.S. Pat. No. 7,343,351,which is hereby incorporated by reference in its entirety. A digitalwallet may be used to facilitate a secure purchase, so the presentinvention may utilize the digital wallet to facilitate a transactionwhich, for example, also utilizes a unique anonymous account code.

In another embodiment, any of the accounts discussed herein may also beassociated with a pool of account identifiers. For example, a clientestablishes a master account with an issuer. A pool of limited useaccount identifiers or secondary account identifiers, that are separateand distinct from the master account, is associated with the masteraccount by the account issuer. Each of the limited use accountidentifiers may be used by the client to conduct transactions as setforth herein. In one embodiment, to utilize the limited use accountidentifiers, the client selects an item to purchase from a second party.The client assigns a purchase order code or other identifying characterstring to the item or items to be purchased, and further indicates anexpected financial amount for the transaction. In some embodiments, anexpected time of the transaction is also provided. This transaction datais then transmitted to an intermediary in a pre-authorization request.Upon receipt of the request, the intermediary selects one of theavailable limited use account identifiers from the pool assigned to theparticular client's master account. The selected limited use account aidentifier is then provided to the client, who in turn, provides it tothe second party for effecting payment for the purchase. The secondparty, in turn, provides the limited use account identifier and afinancial amount due to a transaction mechanism, with the transactionbeing ultimately approved or disapproved by the account issuer or anagent thereof. The authorization for the transaction is dependent uponwhether the financial amount, as well as other data received with thelimited use account identifier matches the data received with theclient's pre-authorization request or is within a predetermined rangethereof. In some embodiments, the authorization may depend on anidentification of the second party, the amount of the transaction,and/or the date of the transaction. If such data match, the transactionmay be approved by the account issuer. After authorization of thetransaction, the account issuer generates an account summary includingthe received financial amount and the purchase order number or otheridentifier received with the request. The account summary may betransmitted to the client for internal reconciliation. Pursuant to someembodiments, limited use account identifiers may be reissued or reusedafter a transaction using the limited use account identifier has settledor after a preauthorization of the limited use account identifier hasexpired.

In further embodiments of the disclosed system, the pool of availablelimited use account identifiers may be assigned prior to any purchaserequests by a client, and the number of available limited use accountidentifiers may be based on the client's purchasing history, or otheranticipated amounts of transactions by the client.

In another embodiment, any of the accounts discussed herein may also beassociated with the ability to authorize a portion of a payment basedupon a partial shipment of items. More particularly, the method mayinclude receiving an initial authorization request, the initialauthorization request including information identifying the transactionincluding information identifying a second party, the first accountidentifier and a transaction amount; identifying a pre-authorizationrecord associated with the first account identifier and determining thatthe transaction amount complies with authorization criteria in thepre-authorization record; and, analyzing the transaction information todetermine if the transaction involves a partial shipment. If thetransaction involves a partial shipment, then only a portion of thepayment may be pre-authorized or authorized.

In another embodiment, any of the accounts discussed herein may also beassociated with a pre-authorization record. More particularly, themethod may include receiving transaction information defining atransaction, the transaction information including a transaction amountand a second party; selecting an available limited use accountidentifier from a pool of limited use account identifiers associatedwith a transaction facilitator to associate with the transaction,wherein the transaction facilitator acts as an intermediary between afirst party and second party; establishing a pre-authorization recordassociated with the selected limited use account identifier, thepre-authorization record including one or more use restrictions based onthe transaction information; associating the selected limited useaccount identifier with the transaction; providing the selected limiteduse account identifier to the transaction facilitator; subsequentlyreceiving an authorization request; and determining whether to approvethe authorization request by comparing terms of the pre-authorizationrecord with the authorization request.

In another embodiment, any of the accounts discussed herein may also beassociated with a manual authorization. For example, a previouslydeclined transaction may be authorized by a party (e.g., any partydiscussed herein), so that a subsequent transaction involving the sameaccount code may be authorized. More particularly, the method mayinclude receiving information identifying a payment account having atleast one of an account-level and a corporate-level restriction on use;identifying a first authorization request that involved the paymentaccount, where the first authorization request was declined for a firstpurchase transaction for failing to comply with the at least one of anaccount-level and a corporate-level restriction on use; creating, inresponse to the declined first authorization request, a manualauthorization record for the payment account and the first purchasetransaction based on information from the first authorization request:and temporarily overriding the at least one of an account-level and acorporate-level restriction on use and allowing approval of a secondauthorization request involving the payment account and a secondpurchase transaction that complies with terms of the manualauthorization record, including matching information from the firstauthorization request.

In one embodiment, the system and method enables the allocation of atleast a portion (or the entire amount) of a charge and/or loyalty pointsto different transaction accounts or sub-accounts. For example, aconsumer may have a transaction account with Citibank, Bank of America,Visa and American Express. The consumer may also have different AmericanExpress accounts (e.g., personal account, corporate account, blue card,gold card, limited use account code, etc) The consumer incurs a chargefor $1000, and the charge may be allocated among one or more of theCitibank, Bank of America, Visa, American Express Corporate and AmericanExpress Blue card accounts.

The allocation may be based upon one or more of, for example, the amountof the transaction, consumer goals, demographic data, locationinformation, loyalty point information, historical transactions,frequency of transactions, past behavior (of consumer, merchant, etc),payment system (operated by payment processor), consumer transactionfees, late fees, interest rates, merchant transaction fees, exchangerates, costs for using the account, vendor information, company/employerrules, biometric information, authorization levels, consumerinformation, merchant information, issuer information, payment processorinformation, the ROC (record of charge), the SOC (summary of charges), apredetermined allocation rule, a dynamic allocation rule (e.g., whichchanges based upon any of the other factors), consumer and/or employerconfirmation (or lack of confirmation), type of account or financialinstrument used for the transaction and/or the like.

The allocation may involve any type of account, account code and/or cardsuch as, for example, a corporate card/account (e.g., centralizedcorporate account paid by the corporation, or corporate account paid byemployee then employee is reimbursed), personal card/account, loyaltyaccount, gift card/account (e.g., open card, private label, etc),purchasing card/account, fuel card/account, shared account (e.g., routescharges and/or loyalty points to a charity account), a third partybilling account, a revolving credit card (charges interest but do notneed to pay in full), and/or charge card (must pay in full, but nointerest). A third party billing account may include consumers providingtheir phone number (or a code which is based upon, accessed in a look-uptable from, or generated from, the consumer's phone number) as theaccount code such that consumers can bill charges to their Sprinttelephone account. The phone number account code and charge informationis routed to Sprint to allow Sprint to handle the account receivablefrom the consumer. The payment processor pays the merchant and entersinto an arrangement with Sprint to settle the charges (e.g., prior to orafter paying the merchant).

The allocation rule may also be, for example, stored on a transactiondevice, stored on a personal digital assistant, acquired from anemployer or third party, generated at the point of sale, associated witha transaction account, stored at the merchant, stored on a server whichserves a group of merchants, and/or stored at a payment processor.

In one embodiment, a consumer may use an American Express Corporateaccount to charge $1000 at a merchant, so the merchant requestsauthorization and obtains settlement from American Express. However, thesystem may allocate the charge by charging $500 to the American ExpressCorporate account, $200 to the Citibank account, $200 to the Bank ofAmerica account, $50 to the Visa account, and $50 to the AmericanExpress Blue card account. These respective charges may appear on theconsumer's billing statements from the various issuers, and AmericanExpress may request reimbursement from the other issuers for therespective charges prior to, and/or after settling with the merchant. Inanother embodiment, American Express may include the entire $1000 on theconsumer's billing statement, then transfer the respective portion ofthe payment remittance (less any transaction fee, etc) to each of theissuers. In one embodiment, the American Express billing statementand/or the other issuer billing statements may indicate how the $1000charge was allocated, so the consumer is able to track the charges fromall issuers involved in the allocation.

The system may also include (or acquire) late fee, payoff requirementsand interest rate information related to the various accounts such thatthe system may determine the optimal allocation of charges to thevarious accounts, based on consumer goals. For example, if a consumerdesires to delay payment of the charges, the system may allocate alarger portion of the charge to a revolving credit card, instead of acharge card that requires payment in full.

The allocation may also be based upon location information. Locationinformation may include the location of the transaction, location of theconsumer, location of the merchant, location of the supplier, locationof the product, origin of the product (or its components), zip codeinformation, city information, mapping information, global positioninginformation, and/or the like. For example, a transaction device mayinclude location technology (e.g., a global positioning system), thesystem may determine location information based on purchase data (e.g.,service establishment number, point of sale terminal information, etc),the system may acquire location information from other sources (e.g.,consumer location based on information from a cellular phone company, orproduct origin location based on SKU or UPC information), etc. In oneembodiment, if an employee uses an American Express corporate card topurchase fuel for a company car while outside of his sales territory,over a certain purchase frequency, over a certain amount, or on aweekend, the system may allocate at least a portion of the charge to theemployee's personal Visa charge card. In another embodiment, the systemmay determine that the employee historically uses his corporate card toobtain gasoline from a certain gas station in a certain city onWednesdays, so if the employee tries to use the corporate card topurchase gas on Saturday in Anaheim near Disneyland, the system mayallocate at least a portion of the charge to the personal chargeaccount.

With respect to vendor information, in one embodiment, if an employeeuses a corporate card to purchase fuel for a company car, the system maydetermine that the employee is distributing product for supplier A(e.g., based on the day of the week), so the system may allocate aportion of the charge to a sub-account associated with supplier A.

With respect to loyalty points, the system may analyze the loyalty pointbenefit associated with various accounts, then allocate the charges tomaximize the loyalty point benefit. The allocation may consider theconsumer goals such as, for example, the desire to obtain a smalleramount of loyalty points in the near term, the desire to obtain a largeramount of points even it may take a longer time to obtain the points,maximize earning or burning of points with certain vendors, etc. Forexample, a Visa account may allocate 500 points for a purchase of onetank of gas, but an American Express account may allocate 1000 pointsafter purchasing ten plane tickets above $1000, so the system mayallocate gas charges to the Visa account and allocate the plane ticketpurchases to the American Express account.

The system may allocate the charge based upon the optimal transactionfees charged by a payment processor, or charged in association with aforeign currency exchange. As used herein, a payment processor includesissuers, acquirers, settlement systems and other systems whichfacilitate authorizing merchant transaction requests, processingsettlement requests and/or handling dispute resolution. For example, thesystem may determine the optimal payment processor to facilitate thetransaction based upon optimal transaction fees for the particularaccounts contemplated for the transaction. In contrast to pre-selectedaccounts, the system may also suggest or allocate the charges amongcertain accounts based upon optimal transaction fees. As one skilled inthe art will appreciate, “optimal” transaction fees may include reducedfees, but the optimal fees may be based on other factors such as, forexample, bulk discounts, processing at certain time periods, meetingcertain requirements, involving certain purchases and/or the like.Additional features related to determining transaction fees may be foundin U.S. Ser. No. 12/264,789, entitled “Customized Financial TransactionPricing” filed on Nov. 4, 2008, and additional features related todetermining the optimal payment processor may be found in U.S. Ser. No.11/164,444, entitled “Systems And Methods For Locating A Payment SystemUtilizing A Wireless Point Of Sale Device” which was filed on Nov. 22,2005, all of which are hereby incorporated by reference.

The allocation may be implemented using a pre-defined rule; selecting orentering a rule via a webpage, online or otherwise submitting a request(e.g., via email, fax, cell phone, customer service representative,etc); a message sent to and/or from a personal digital assistant; aconfirmation, denial or non-response to an allocation request; and/or anallocation request sent to a consumer, relative/guardian, employer,payment processor or third party. For example, the consumer may enterinformation into a webpage regarding a pre-determined percentage oramount to allocate to various accounts for certain transactions. Thevarious scenarios and options discussed herein may be included asdrop-down lists, such that the consumer may choose various alternativearrangements based on the specific situations.

For example, the consumer may establish that 50% of a charge over $250should be allocated to the Visa corporate card when the consumer is inCalifornia on any Wednesday, 35% of the charge should be allocated tothe company purchasing card if the expense relates to office supplies,and 15% of the charge should be allocated to the consumer's personalMasterCard revolving credit card during promotional periods when itawards over 2 points per dollar purchased, but only until 10,000 pointsare earned, then the 15% should be allocated to the consumer's Bank ofAmerica account.

The system may also suggest an allocation. The system may suggest theallocation prior to, during or after a transaction. The system may alsosuggest an allocation based on past behavior. For example, if theconsumer previously allocated a certain percentage of an office supplycharge to his Citibank card, and a certain percentage of his gasexpenses to his American Express corporate card, then the system maysuggest a similar allocation during an office supply transaction (e.g.,suggestion appears on the POS terminal, or sent to the consumer'scellular phone) or the system may suggest a similar allocation when theconsumer is establishing the allocation rules online.

In another embodiment, an employer may establish that any charge on thecompany Visa corporate card over $500 generate a notification to themanager (e.g., Blackberry device). The system may already have storedinformation related to the employee's charge accounts, so systemdisplays the various charge accounts on the manager's Blackberry, alongwith the employee's transaction history and current charge request. Themanager can then analyze how much the employee already spent onentertaining a certain client, then the manager can indicate anallocation of the charge among the employee's personal and businesscharge accounts. The system may also include the employee having asecond approval or a method for contesting the allocation by theemployer. Additionally, if the manager does not reply within a certaintime period, then the system may allocate the charge based upon a “noreply” allocation rule.

The system may also enable one or more of the transaction accountissuers or payment processors to participate in any phase of thetransaction (e.g., pre-authorization, authorization, settlement, etc).For example, if the consumer uses an American Express charge card topurchase a product, but a rule exists to allocate 50% of the charge to aVisa account and 25% of the charge to a Bank of America account, thenVisa may or may not be involved in the authorization process. In otherwords, when the authorization request is sent to American Express,another secondary authorization request for at least a portion of theamount (e.g., 50%) may also be sent to Visa (e.g., directly from themerchant, from the consumer, American Express creates or forwards thesecondary authorization request to Visa, etc). In one embodiment,American Express may recognize the primary authorization request asassociated with a transaction that involves a charge allocation, thenAmerican Express may forward at least a portion of the authorizationrequest to Visa. Visa may then create and send a secondary authorizationcode. The Visa secondary authorization code may be sent back to themerchant directly or to American Express. In one embodiment, thesecondary authorization code may indicate that it is only anauthorization for a portion of the transaction such that a primary orother authorization code should also be obtained. The parties in suchallocated transactions may also utilize one or more pre-authorizations,manual authorizations, limited use account numbers and/or any of theother features set forth herein.

In another embodiment, Visa sends its secondary authorization code toAmerican Express. If American Express accepts the Visa authorizationcode, American Express incorporates the Visa authorization into theAmerican Express authorization process. American Express then sends oneor more authorization codes to the merchant or consumer which reflectthe combined authorization of American Express and Visa for at least aportion of the transaction amount or the entire transaction amount.

With respect to settlement, in one embodiment, the merchant may send onesettlement request to American Express related to a transaction,American Express settles with the merchant, then American Express seeksreimbursement from the other account issuers of which the charge wasallocated. In another embodiment, the merchant sends multiple settlementrequests, based upon the allocated transaction, to the respectiveacquirers in order to facilitate settlement (based upon the variousissuers and including the specific issuer authorization code). Inanother embodiment, to help reduce fraud, American Express obtainspartial or full payment for the transaction prior to settling with themerchant. For example, American Express may send an invoice to theconsumer, obtain payment from the consumer for the charges, obtainpayment from the other issuers involved in the allocated transaction,then American Express would pay the merchant (after American Expressreceived a portion or all of the funds related to the allocatedtransaction).

As one skilled in the art, will appreciate, the transaction mechanism ofthe present invention may be suitably configured in any of several ways.It should be understood that the transaction mechanism described hereinwith reference to FIG. 21 is but one exemplary embodiment of theinvention and is not intended to limit the scope of the invention asdescribed above. FIG. 21 illustrates an exemplary transaction mechanism2100 comprising a C2C Service 2104; a Transaction Manager 2106; aBusiness Rules Engine 2108; an Express Net Interface Manager 2110; aneMailers Engine 2112; an SSL Gateway Interface Manager 2114; a C2CLogging Engine 2116; and a Financial Transaction Submission Daemon 2118.

The C2C Service 2104 suitably processes initial transaction requestsfrom Internet users 2102. Exemplary processes performed by the C2CService 2104 include requesting transaction information, such as cardand/or DDA information, from an Internet user 2102 who has logged intothe transaction system; validating the data entered by an Internet user2102; and submitting a completed transaction invoice to the TransactionManager 2106. The C2C Service 2104 communicates with the othercomponents of the system through any suitable communications link,including a network connection such as an Intranet, extranet, and/or thelike.

The Transaction Manager 2106 performs a variety of processes whichfacilitate a transaction between a seller and a purchaser. Theseprocesses may include creating transaction invoices and managing them,including updating a particular transaction invoice at the variousstages of the transaction process; sending emails to sellers andpurchasers using the E-Mailers Engine 2112; and processing requests fromthe Virtual Point of Sale (VPOS) Capture Daemon for transactions whichare eligible for submission to the financial capture systems, asdescribed in greater detail below.

The Business Rules Engine 2108 preferably provides access to a varietyof operating standards that may be applied to any given transactionbetween a seller and a purchaser. The applicable operating standards mayinclude, but are not limited to, any of the following: (1) given atransaction type and a transaction, Business Rules Engine 2108 mayreturn a suitable pricing model to be applied to the transaction; (2)Business Rules Engine 2108 may compute a transaction fee based upon acertain number of basis points, which preferably is a configurableparameter generated from a suitable fee table (for example, one basispoint=0.01%, so 375 bp=3.75% of the total price of the transaction); (3)Business Rules Engine 2108 may apply a flat transaction fee; and/or (4)given a transaction and a transaction type, Business Rules Engine 2108may apply a fraud model to the transaction, wherein the exemplary fraudmodel may include any of the following: (a) authorization for thepurchaser's part in the transaction, including billing addressverification and 4DBC verification of the purchaser; (b) verification ofa lack of any relationship between the purchaser and the seller, whereinall transactions showing a relationship (such as “self” or otherpersonal relationship) between the purchaser and the seller may be“failed” or otherwise terminated; (c) application of a 3-strike rule,wherein the transaction is failed or terminated if a 3^(rd) attempt toauthorize the transaction fails and an email is sent to the sellerproviding an explanation for the cancellation of the transaction; and(d) verification that the transaction amount has not exceeded anyprescribed limits, such as a limit on the transaction amount and/or alimit regarding the maximum number of transactions that may be conductedbetween a first party and any other party during some defined period oftime (such as per day, per week, per month, etc.). In one embodiment,any applicable transaction limits are provided as configurableparameters by the Business Rules Engine 2108.

In the case of both verification of the purchaser's billing address andverification of purchaser/seller non-relationship, a ‘system notavailable’ response is possible, in which case the Business Rules Engine2108 may recommend either a time-out or that the transaction beterminated.

In one embodiment, the non-relationship verification is the firstprocess sent to the credit authorizations system (CAS) from thetransaction mechanism 2100, since the data for this process preferablyis contained within the CAS rather than a separate cardmember system(IMS, Triumph). The CAS is an online system which analyzes chargerequests and either approves the charge requests or refers them to anAuthorizer for a decision. CAS preferably contains a negative file, adelinquency file, and an accumulative file. If the purchaser and sellerpass the non-relationship verification, then an authorization request(with AAV and 4DBC) is sent. The authorization request preferablyinvolves CAS accessing a suitable cardmember system to verify thebilling address.

The Express Net Interface Manager 2110 communicates with the ExpressNet, the utility which processes user registration and manages theaccounts of registered users. The Express Net Interface Manager 2110accesses the Express Net and acquires any suitable user data which maybe desired to process a particular pending transaction. Preferably, theExpress Net Interface Manager 2110 acquires a list of the Internetuser's registered cards and/or DDAs as well as other unique datapertaining to the Internet user 2102, wherein the exemplary informationmay be used to process the transaction.

The eMailers Engine 2112 preferably sends suitable email notificationsand/or confirmations to both the seller and the purchaser in the case ofeither a merchandise transaction or a transfer of funds. For example,the eMailers Engine 2112 may send an email comprising a notificationwhich may: (1) notify a purchaser, preferably with an encrypted URL, ofa transaction or funds transfer initiated by a seller and providesuitable means for the purchaser either to accept or decline thetransaction or funds transfer; (2) copy the seller on the notificationsent to the purchaser; and/or (3) indicate to both a seller and apurchaser that the purchaser has either accepted or declined atransaction or transfer of funds.

The SSL Gateway Interface Manager 2114 preferably communicates with theSSL Gateway, which preferably includes a Payment Gateway Client Classand a CAS Authentication Component. The SSL Gateway is a message andfile distribution system which accepts authorization requests online anddistributes those authorization requests to the proper authorizationsystem. The Payment Gateway Client Class preferably processes all of theprotocol and transport level responsibilities that are may be used forcommunicating with the Payment Gateway Server, which operates as a partof the SSL Gateway. Preferably, the defined protocols include theaddition of a MIME header to all XML messages sent to the paymentgateway and the use of TCP/IP sockets for communication with the PaymentGateway. The CAS Authentication Component preferably is responsible forperforming the CAS financial authorization processes (ISO8583) as wellas performing the CAS non-relationship verification processes based uponthe new ISO message.

The C2C Logging Engine 2116 preferably audits and error logs all eventsin the transaction system 2100. Preferably, the C2C Logging Engine 2116logs errors in the transaction system 2100 into a flat file. Preferably,the CA Unicenter agent for production support uses this flat file.

The Financial Transaction Submission Daemon 2118 preferably submits eachtransaction's financial transaction record, such as a credit and/ordebit Virtual Point of Sale (VPOS) record that results from a particularcard to card or card to DDA transaction, to a VPOS Acceptance System2202 via the SSL Gateway 2204, as better seen in FIG. 22. Preferably,each individual financial transaction record is submitted to the VPOSAcceptance System as it is received, without being processed as part ofa batch file. The VPOS Acceptance System receives the financialtransaction record, formats the financial capture file, and forwards thefinancial capture file to the SSL Gateway. The SSL Gateway then forwardsthe financial capture file to the appropriate financial capture system.The submission of the financial transaction record preferably is basedupon a message-based protocol that is implemented by the VPOS AcceptanceSystem.

Although the invention has been described herein as facilitatingcommercial transactions between parties residing at remote locations,one of ordinary skill in the art will appreciate that the invention isnot so limited and includes the facilitation of commercial transactionsbetween co-located parties.

It should be understood, however, that the detailed description andspecific examples, while indicating exemplary embodiments of the presentinvention, are given for purposes of illustration only and not oflimitation. Many changes and modifications within the scope of theinstant invention may be made without departing from the spirit thereof,and the invention includes all such modifications. The correspondingstructures, materials, acts, and equivalents of all elements in theclaims below are intended to include any structure, material, or actsfor performing the functions in combination with other claimed elementsas specifically claimed. The scope of the invention should be determinedby the appended claims and their legal equivalents, rather than by theexamples given above. For example, the steps recited in any methodclaims may be executed in any order and are not limited to the orderpresented in the claims. Moreover, no element is essential to thepractice of the invention unless specifically described herein as“critical” or “essential”.

We claim:
 1. A method, comprising: receiving, at a first computer systemassociated with a first entity, a transaction authorization request thatspecifies an amount owed to a receiving party and that specifies a firstfinancial account identifier issued by the first entity; the firstcomputer system applying an allocation rule to the transactionauthorization request to determine first and second portions of theamount owed to the receiving party, wherein the first portion is to befunded by a first financial account and the second portion is to befunded by a second financial account; the first computer system sendinga partial payment request to a second computer system, wherein thepartial payment request specifies a second financial account identifierand the second portion of the amount owed to the receiving party; thefirst computer system sending a message to the receiving party, whereinthe message indicates authorization of payment for the first and secondportions of the amount owed to the receiving party.
 2. The method ofclaim 1, further comprising: collecting, by the by the first computersystem and from a second entity, the second portion of the amount owedto the receiving party; and causing the second portion of the amountowed to the receiving party to be distributed to the receiving party. 3.The method of claim 1, wherein the first entity is a credit card issuerthat issued a first credit card associated with the first financialaccount, and wherein the transaction authorization request includes anaccount number associated with the first credit card.
 4. The method ofclaim 1, wherein the first financial account identifier is for the firstfinancial account.
 5. The method of claim 1, wherein the first financialaccount identifier is for a financial account other than the firstfinancial account.
 6. The method of claim 1, further comprising applyingthe allocation rule to the transaction authorization request todetermine a third computer system; and, authorizing the first portion ofthe amount owed to the receiving party by sending a different partialpayment request for the first portion to a third computer system.
 7. Themethod of claim 1 , further comprising: the first computer systemreceiving a denial of the partial payment request from the secondcomputer system; in response to the denial of the partial paymentrequest, the first computer system applying the allocation rule to thetransaction authorization request to determine a third computer system;and, the first computer system sending an additional partial paymentrequest to the third computer system, wherein the additional partialpayment request specifies the first portion of the amount owed to thereceiving party.
 8. The method of claim 1, further comprising the firstcomputer system causing at least the first and second portions of thespecified amount owed to the receiving party to be transferred to thereceiving party, wherein the receiving party receives at least one of amonetary amount, a non-monetary amount, a loyalty point amount, or amonetary equivalent value.
 9. The method of claim 1, wherein a sameconsumer is associated with the first and second financial accounts. 10.A first computer system associated with a first entity that issued afirst financial account, comprising: a processor; and acomputer-readable storage medium having stored thereon instructions thatare executable by the processor to cause the first computer system toperform operations comprising: receiving a transaction authorizationrequest that specifies an amount owed to a receiving party and thatspecifies a first financial account identifier; retrieving an allocationrule; applying the allocation rule to the transaction authorizationrequest to determine first and second portions of the amount owed to thereceiving party, wherein the first portion is to be funded by a firstfinancial account and the second portion is to be funded by a secondfinancial account; respectively sending first and second partial paymentrequests to at least one other computer system, wherein the first andsecond partial payment requests respectively specify the first andsecond portions of the amount owed to the receiving party, and whereinthe first and second partial payment requests respectively specifysecond and third financial account identifiers issued by at least one ofa second entity or a third entity; and based on receiving a response tothe first and second partial payment requests, transmitting a message tothe receiving party, wherein the message indicates authorization ofpayment for the first and second portions of the amount owed.
 11. Thesystem of claim 10, wherein retrieving the allocation rule includes atleast one of: reading the allocation rule from a storage deviceaccessible to the first computer system, or using a networkcommunication device of the first computer system to send a request forthe allocation rule to a remote computer system.
 12. The system of claim11, wherein the request for the allocation rule specifies the firstfinancial account identifier.
 13. The system of claim 10, whereinapplying the allocation rule includes determining a third portion of theamount owed to the receiving party; and wherein the operations furthercomprise using one or more rules specified by the first entity toauthorize payment for the third portion of the amount.
 14. The system ofclaim 10, wherein receiving the response to the first and second partialpayment requests includes receiving a first response corresponding tothe first partial payment request and includes receiving a secondresponse corresponding to the second partial payment request.
 15. Anon-transitory computer-readable storage medium having stored thereoninstructions that are executable by a processor of a first computersystem associated with a first entity to cause the first computer systemto perform operations comprising: receiving a transaction authorizationrequest that specifies an amount owed to a receiving party and thatspecifies a first financial account identifier issued by the firstentity; applying an allocation rule to the transaction authorizationrequest to determine first and second portions of the amount owed to thereceiving party, wherein the first portion is to be funded by a firstfinancial account and the second portion is to be funded by a secondfinancial account; sending a partial payment request to a secondcomputer system, wherein the partial payment request specifies a secondportion of the amount owed to the receiving party and a second financialaccount identifier associated with a second entity; and sending amessage to the receiving party, wherein the message indicatesauthorization of payment for the first and second portions of the amountowed to the receiving party.
 16. The non-transitory computer-readablestorage medium of claim 15, wherein the operations further compriseauthorizing the first portion of the amount based on one or more rulesspecified by the first entity.
 17. The non-transitory computer-readablestorage medium of claim 15, wherein the first entity is at least one ofa credit card issuer or a debit card issuer.
 18. The non-transitorycomputer-readable storage medium of claim 15, wherein the operationsfurther comprise retrieving the allocation rule from a third entityprior to applying the allocation rule but subsequent to receiving thetransaction authorization request.
 19. The non-transitorycomputer-readable storage medium of claim 15, wherein the operationsfurther comprise retaining a third portion of the amount owed to thereceiving party as a transaction fee.
 20. The non-transitorycomputer-readable storage medium of claim 15, wherein the firstfinancial account identifier is for the first financial account.